Hi,
I'd like to know what is the preferrable way,
in a Linux kernel module, to get a notification
at a time in the future so to avoid as much as
possible unpredictable delays due to possible
device driver interferences. Basically, I would
like to use such a mechanism to preempt (also)
real-time tasks for the purpose of temporally
isolating them from among each other.
Is there any prioritary mechanism for specifying
kind of higher priority timers, to be served as
soon as possible, vs. lower priority ones, that
could be e.g. delayed to ksoftirqd and similar ?
(referring to 2.6.17/18, currently using add_timer(),
del_timer(), but AFAICS these primitives are more
appropriate for "timeout" behaviours, rather than
"precise timing" ones).
Thanks, regards,
T.
On Thursday 05 October 2006 17:13, you wrote:
> Hi,
>
> I'd like to know what is the preferrable way,
> in a Linux kernel module, to get a notification
> at a time in the future so to avoid as much as
> possible unpredictable delays due to possible
> device driver interferences. Basically, I would
> like to use such a mechanism to preempt (also)
> real-time tasks for the purpose of temporally
> isolating them from among each other.
>
> Is there any prioritary mechanism for specifying
> kind of higher priority timers, to be served as
> soon as possible, vs. lower priority ones, that
> could be e.g. delayed to ksoftirqd and similar ?
> (referring to 2.6.17/18, currently using add_timer(),
> del_timer(), but AFAICS these primitives are more
> appropriate for "timeout" behaviours, rather than
> "precise timing" ones).
There is no notion of priority in the current timer system, although that idea
has been tossed around a bit. As far as an appropriate timer for events, as
opposed to timeouts, consider using ktimers + hrtimers (both of which are
included in the -rt patchset). The are optimized for times that you expect
to expire (as opposed to timeouts which usually don't) and can provide
accuracy to the 10s of microseconds.
http://tglx.de/ktimers.html
http://tglx.de/hrtimers.html
http://people.redhat.com/mingo/realtime-preempt/
Regards,
--
Darren Hart
IBM Linux Technology Center
Realtime Linux Team
On Fri, 6 Oct 2006, Tommaso Cucinotta wrote:
> I'd like to know what is the preferrable way,
> in a Linux kernel module, to get a notification
> at a time in the future so to avoid as much as
> possible unpredictable delays due to possible
> device driver interferences. Basically, I would
> like to use such a mechanism to preempt (also)
> real-time tasks for the purpose of temporally
> isolating them from among each other.
>
> Is there any prioritary mechanism for specifying
> kind of higher priority timers, to be served as
> soon as possible, vs. lower priority ones, that
> could be e.g. delayed to ksoftirqd and similar ?
> (referring to 2.6.17/18, currently using add_timer(),
> del_timer(), but AFAICS these primitives are more
> appropriate for "timeout" behaviours, rather than
> "precise timing" ones).
This is possible via a hardware interrupt. HPET chips and also the PIT
provide the ability to schedule an ihterrupts in the future. The periodic
timer tick is such a mechanism that is also used by the scheduler to
preempt processes. If the interrupt has sufficiently high priority then
you could avoid many interrupt holdoffs. However, you may not be able to
do much since you have no process context. Plus this may be nothing else
than duplicating already existing functionality.