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). -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
