[Top] [All Lists]

Re: [PATCH 3/5] Deforest the function pointer jungle in the time code.

To: Ralf Baechle <>
Subject: Re: [PATCH 3/5] Deforest the function pointer jungle in the time code.
From: "Maciej W. Rozycki" <>
Date: Fri, 15 Jun 2007 15:08:14 +0100 (BST)
Cc: Franck Bui-Huu <>, Thomas Bogendoerfer <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <> <> <> <> <>
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 

> 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. ;-)


<Prev in Thread] Current Thread [Next in Thread>