Re: Re: [Rtlinuxgpl] Interrupt Prioritization

> 
> 
> On Wed, 4 Jan 2006, Der Herr Hofrat wrote:
> 
> > actually all interrupts hit the system - even the non-RT interrupts have to
> > be processed by the interrupt interception code in rtl_core->rtl_intercept
> > or one would start losing interrupts. The runtime of the code is in the range
> 
> In light of the above: Is it evil, then.. to unconditionally do an 
> rtl_critical(flags) at the beginning of my high priority periodic task and 
> an rtl_end_critical(flags) at the end of the period, right before 
> sleeping?  Would this mean I might lose interrupts? My periodic task 
> sometimes takes as long as 1ms to execute.

if you receive one interrupt of a given vectro during this time then you will
recive it - the second one would be lost (the PIC only has one bit to flag an
interrupt). disabling interrupts for 1ms will though likely not cause any 
noticable problems for the non-RT interrupt, you will be losing some network
packets - but those will be retransmitted, and most other devices are fairly
tolerant aswell (mouse,keyboard), you could have problems with some disks 
though.


> 
> > of a few 100 nanoseconds if it is in cache, worst case is in the range of 2us
> > on a 1.6GHz AMD Duron. The timer interrupt does fire while executing a high
> > priority task - the reason for this is that we don't know the execution times
> > of the tasks, thus it is not posible to say if the next timer to expire will
> > be in the middle of the current task or not, so we have to set the timer in
> > any case and check (by calling the scheduler) when it fires. So currently
> > the way RTLinux/GPL does this is simply to find the next timer that would
> > expire which has the the highest priority and the closest expire time, but
> > this need not be higher priority than the currently running task. Thus it
> > can happen that the timer fires and finds that the current task is still
> > the highest runnable task and reschedules it.
> >
> > You can see this effect if you run a long highe priority task and let a lower
> > priority task run with a very high frequency, then check the variance of the
> > high priority tasks execution time.
> >
> > If one would know the execution times of the tasks this inefficiency could be
> > elminated.
> 
> Right I see.  Hmm.  It might be nice if periodic tasks could inform the 
> scheduler of what their max runtime is per period.  Oh well -- that might 
> be a future feature I guess.

The problem is that the execution time is not very deterministic, even with
disabled interrupts there is some variance. The scheduler could esaly record
the execution times of tasks, but the problem is that it would have to take
the longest execution time to select the next timer event - thus potentially
increasing the jitter a lot. If you were to take the shortest execution time
it would result in the timer fireing into the task again - so there is no
clean soution on systems with non-deterministic execution times.

> 
> I can live with the 100ns penalty when the timer fires.  I am a little 
> worried about the fact that rtl_intercept can get called quite often 
> during my high priority realtime task.
> 
> My measurements, though, show that it doesn't really interfere too much.
>
it should not - if it is called often then you can expect it to be in cache
and will not notice much of it - its probably not much more than a single
cache line.

hofrat
_______________________________________________
Rtl mailing list
[email protected]
http://hq.fsmlabs.com/mailman/listinfo/rtl
http:/www.rtlinux-gpl.org/