Re: [PATCH 01/22] cpuidle take2: Core cpuidle infrastructure

[Len Brown <lenb@kernel.org>]

On Thursday 15 March 2007 08:31, Andi Kleen wrote:
> Len Brown <lenb@kernel.org> writes:
> > +
> > +/**
> > + * cpuidle_idle_call - the main idle loop
> > + *
> > + * NOTE: no locks or semaphores should be used here
> > + * FIXME: DYNTICKS handling
> 
> I don't think you can merge anything anymore with such a FIXME.

Certainly it need to work well with NOHZ before it can go upstream.
Indeed, NOHZ is one of the reasons for doing cpuidle in the first place.

But then NOHZ is probably going to take some time to mature also,
certainly it can't be considered mature until it is also in the 64-bit kernel.

The question becomes if NOHZ matures w/o cpuidle -- do we need
to modify the existing tick-based ACPI idle code before cpuidle?

> Besides cpuidle is a pretty radical change outside ACPI and I would recommend to 
> make a few review cycles over linux-kernel and likely linux-arch. 

I agree.  acpi-test and -mm would not be sufficient exposure for generic code.

> For me it's not clear it has enough advantages for its amount of code

Understood.  Measurements will tell.
This is the very reason we created tools which can simultaneously
measure performance and battery life: http://sourceforge.net/projects/bltk

I think that for cpuidle to go upstream, its default should not require any user-space changes
to work as well as the old code.  If some sysfs hooks are available to get added
value, such as useful statistics or modifying policy, that is something that
user-space can safely ignore and not break.

-Len