Re: Re: [Rtlinuxgpl] Interrupt Prioritization

"Calin A. Culianu" <[email protected]> Wed, 4 Jan 2006 17:50:03 -0500 (EST)
Newsgroups gmane.linux.real-time.rtlinux.general
Message-ID <[email protected]>

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.

> 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.

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.

-Calin

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