On Thu, 27 May 2010, Thomas Renninger wrote: > On Thursday 27 May 2010 04:42:31 Len Brown wrote: > > From: Len Brown <len.brown@xxxxxxxxx> > ... > > CONFIG_INTEL_IDLE=m is not recommended unless the system > > has a method to guarantee intel_idle loads before ACPI's > > processor_idle. > Then it should better be declared bool instead of tristate until it > works. intel_idle as a module works fine, and tristate should be retained. If user-space chooses to load intel_idle before acpi processor, then it correctly handlees idle states and acpi correctly yields. If user space gets them in the other order, then user-space gets what it asked for. The fact that a typical desktop distro load acpi-cpufreq first, and that depends on the acpi processor driver should not prohibit intel_idle from being modular. Indeed, intel_idle has every right to be moduler on a system where CONFIG_ACPI=n... > > This driver does not yet know about cpu online/offline > > and thus will not yet play well with cpu-hotplug. > What means does not play well yet, suspend or manually offlining a core > will eventually (for sure?) hang the machine? It means less power savings savings than optimal for processors not present at module load time. > If this is known broken, should this already be spread through > linux-next? If you know somebody with a system that supports CPU hot-add on one of the processors supported by intel_idle, and they are willing to test linux-next, please have them contact me. thanks, -Len Brown, Intel Open Source Technology Center _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
