On Fri, 15 Jun 2007, Ralf Baechle wrote: > The cp0 timer may have disadvantages but it certainly is the timer with > the lowest overhead to program, usually the timer with the highest > resolution. Unless in the rare cases where cp0 cannot be used because > it cannot trigger interrupts or the CPU clock is variable I think it will > always be the clockevent device of choice. No argument about the overhead or the resolution, but these are the kinds of properties that make it more appropriate for other purposes like profiling or other short interval measurements, not necessarily for timekeeping. > The tickless kernel needs something that can be used as oneshoot timer. A periodic timer typically works here just fine -- just "forget" about the future shots. ;-) Even the miserable 8254/8259 combination is fine as the former in the mode #2 only deasserts its output for its one input clock, so the latter will only miss an interrupt if it has been on hold for much too long anyway. With an interrupt controller that implements real edge-triggered inputs even this single clock is not an issue. > > Note that the 8254 can be reprogrammed into a one-shot mode, but somehow > > nobody does it. ;-) Similarly for the local APIC timer that is used for > > scheduling on i386 systems (if available). > > Actually modern i386 kernels use it in both modes. But this can't help Oh really? How many clone chipset bugs has it triggered? ;-) > over the fact that the i8253/i8254 is a horrible chip with extremly slow > access times so it's only used as the fallback when everything else fails. The chip is typically in the south bridge these days, so the access time is not as bad itself as it used to be when it was a discrete one somewhere on the x-bus, but the actual problem is the typical Intel baroque way of accessing the counter: ask it to latch the current value, then issue two reads to retrieve the two halves of the counter, plus check the lower half has not overflown into the upper one meanwhile in case the latch command did not work because of a chipset bug. ;-) Maciej
