Re: [PATCH] dynamic tick patch

[Tony Lindgren <tony@atomide.com>]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> [050118 20:22]:
> On Tue, 2005-01-18 at 16:05 -0800, Tony Lindgren wrote:
> > Hi all,
> > 
> > Attached is the dynamic tick patch for x86 to play with
> > as I promised in few threads earlier on this list.[1][2]
> > 
> > The dynamic tick patch does following:
> >
> > .../...
> 
> Nice, that's exactly what I want on ppc to allow the laptops to have the
> CPU "nap" longer when idle ! I'll look into adding ppc support to your
> patch soon.

Great!

> BTW. Is it possible, when entering the "idle" loop, to quickly know an
> estimate of when the next tick shoud actually kick in ?

Yes, see next_timer_interrupt() for that. The interrupt loop should
be pretty much the same on all archs. Then calling the timer
interrupt from other interrupts removes any latency issues with the
timer. But that's pretty much all the patch does.

> Also, looking at the patch, I think it mixes a bit too much of x86
> things with generic stuffs... like pm_idle an x86 thing. 

Yes, the idle module should probably be in drivers/acpi or something
to allow loading other custom PM modules.

> Other implementation details comments: Do you need all those globals to
> be exported ? And give them better names than "ltt", that makes using of
> system.map quite annoying ;)

Oops, ltt, is probably left-over from low-tick-timer that I used
first as a name... I'll fix that :)

> I don't understand your comment about "we must have all processors idle"
> as well... 

Hmmm, maybe it's not needed any longer? Have to try it out. I had
some issues with SMP when I started doing the patch.

> So while the whole thing is interesting, I dislike the actual
> kernel/dyn-tick-timer.c implementation, which should be moved to arch
> stuff at this point imho.

Yeah, there's not much shared code yet, when I started I expected to
share more code between ARM and x86. But the timer framework is
quite arch specific. So far only registering and /sys control to 
enable seems common. Maybe some inline functions too, but a common 
header might be enough.

Regards,

Tony