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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
