In-kernel precise timing.

In-kernel precise timing.

[Tommaso Cucinotta]

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.

Re: In-kernel precise timing.

[Darren Hart]

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

Re: In-kernel precise timing.

[Christoph Lameter]

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.