On Thu, 2007-10-11 at 22:47 +0200, Jan Kiszka wrote:
> This patch for SVN trunk fixes most of the current bugs around hardware
> timer takeover and release from/to Linux. Tested and found working here
> (including SMP):
> - 2.6.22, APIC, highres=off, nohz=off
> - 2.6.22, APIC, highres=on, nohz=on
> - 2.6.20, APIC
> Tests to be done:
> - 2.6.22, PIT (currently building...)
> - 2.6.20, PIT
> Things became quite complex in i386/hal.c now. Some of this complexity
> might be avoidable if RTHAL_APIC_TIMER_VECTOR equalled
> LOCAL_TIMER_VECTOR. What's the reason for this? Is it something related
> to pre-highres times of Linux (ie. 2.6.20 and earlier)? Can we overcome
> it, at least for recent kernels?
The way it works resembles the way Linux works around an issue raised by
broken APIC hardware, whose timer bluntly stalls when entering C3. For
this reason, Linux keeps the i8253 as the master tick device, and
broadcasts the APIC-based local timer vector on all CPUs from the tick
handler. Not doing so would stop the timekeeping when entering a sleep
mode (this what the tick-broadcast mode is about with generic clock
events support in recent kernels).
This said, we do rely on the APIC timer to program the delivery of
RTHAL_APIC_TIMER interrupts in oneshot mode, so the above work around
does not help us a lot when it comes to C3 on broken hardware anyway.
(Not to speak of the TSC which may stop when entering C2 or get
corrupted in C3 in many cases too...)
Another issue to take into account is the cost of timekeeping through a
Xenomai host timer and explicit propagation of a faked LOCAL_TIMER
interrupt via the I-pipe, from the real-time domain to the root domain
(what we would have to do in order to recycle the local timer vector),
compared to the cost of letting the Linux timekeeping stuff live its own
life in parallel, without any intervention from the Xenomai side.
To sum up, I'd say that we could work the way we are already running in
PIT mode, and relay host ticks to Linux, freeing the local timer
interrupt for our own use. But this may also be more expensive for the
real-time side. We are lacking some benchmarks here, but this could be
tested quite easily (we would need to disable IRQ0 when the host ticking
service is handed over to Xenomai though).
Xenomai-core mailing list