On Thursday 15 March 2007 08:31, Andi Kleen wrote: > Len Brown <lenb@xxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
