Re: Re: [Rtlinuxgpl] Interrupt Prioritization

> 
> 
> On Tue, 3 Jan 2006, Victor Yodaiken wrote:
> 
> > On Tue, Jan 03, 2006 at 05:48:35PM -0500, Calin A. Culianu wrote:
> >> OK.  I get it.  One last question.  "If B is running and C becomes
> >> runnable... ".
> >>
> >> That happens if the timer interrupt fires, right?
> >>
> >> So that means that the timer interrupt is always on when rt tasks are
> >> running?
> >>
> >> Is that always ok?  I mean doesn't that sort of introduce lots of jitter?
> >
> > Not on modern machines and the alternative is to let a scheduled high
> > priority task wait on a lower priority task.
> 
> Ok, I see.  I suppose intercepting the timer interrupt and making a 
> decision of what to schedule probably only costs you a few hundred nanos 
> anyway.
>
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
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.

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