Re: Tickless/dyntick kernel, highres timer and general time crapectomy

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

On Thu, Jun 07, 2007 at 03:11:48PM +0200, Franck Bui-Huu wrote:

> Actually I'm wondering if we shouldn't create a new file
> "arch/mips/kernel/time2.c" which will be a complete rewrite of the
> old one (interrupt handler, function pointers, clocksource,
> clockevent). This file would be the future replacement of the old
> time.c. This new file would be used only if the board have been
> updated accordingly. That may help to migrate...

And we'll still be stuck with the compat crap for years - no thank you.
One of the strength of Linux has always been that if necessary we've been
able to turn the code base upside down as needed - even if sometimes it
takes a snow plough to move old stuff out of the way ;-)

> >You can mask the count/compare interrupt in the status register like any
> >other interrupt.  Keep in mind that on many CPUs this interrupt is
> >shared with the performance counter interrupt so cannot always be
> >disabled.
> 
> Well this interrupt could be shared with other devices too, couldn't it ?
> If so only the board code can disable it.

No, the boot mode bit controls a multiplexer so there is either count/compare
or the external interrupt.

> >There is no other disable bit for this interrupt than the IE bit in the
> >status register.  So it may just have to be ignored.
> >
> 
> That would mean we can't have a tickless system in these cases, wouldn't
> it ?

It would simply mean we will receive a useless every 2^32 cycles - nothing
terrible.  The tickless kernel isn't really tickless.  It's more accurately
called dyntick.  One thing that keeps us from completly getting rid of
regular timer interrupts under all circumstances is the current scheduler.
Only if a CPU is idle Linux can stop the regular timer interrupts for it.
With all the software interrupts that happen to be running on a usual
system we expect just a hand full of interrupts per second.  And the good
news is that mingo's current scheduler work is going to remove the concept
of time slices from the scheduler and once that is done we _finally_ will
be able to go even on non-idle CPUs.

  Ralf