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

[Ralf Baechle <ralf@linux-mips.org>]

On Fri, Jun 15, 2007 at 03:08:14PM +0100, Maciej W. Rozycki wrote:

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

That's pretty much how for example on an R1 core the compare interrupt
has to be used - IE7 is shared with the performance counter so can't be
disabled and as the result if the cp0 clockevent device is unused we will
get one useless but also harmless interrupt every 2^32 cycles.

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

I'm sure you couldn't miss the screaming on linux-kernel ;-)

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

Actually these days it seems to be living inside the southbridge behind
an extremly slow interface which is optimized for minimum connections to
the rest of the southbridge.  So I'm told the access time is still around
2µs which is basically as crappy as it always has been.

  Ralf