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/