Messages in this thread |  | | Date | Mon, 12 Feb 2007 20:22:01 -0500 | From | Dave Jones <> | Subject | Re: [PATCH 1/3] Introducing cpuidle: core cpuidle infrastructure |
| |
On Mon, Feb 12, 2007 at 10:39:25AM -0800, Venkatesh Pallipadi wrote: > > Introducing 'cpuidle', a new CPU power management infrastructure to manage > idle CPUs in a clean and efficient manner. > cpuidle separates out the drivers that can provide support for multiple types > of idle states and policy governors that decide on what idle state to use > at run time. > A cpuidle driver can support multiple idle states based on parameters like > varying power consumption, wakeup latency, etc (ACPI C-states for example). > A cpuidle governor can be usage model specific (laptop, server, > laptop on battery etc). > Main advantage of the infrastructure being, it allows independent development > of drivers and governors and allows for better CPU power management. > > A huge thanks to Adam Belay and Shaohua Li who were part of this mini-project > since its beginning and are greatly responsible for this patchset.
interesting. Though I wonder about giving admins _more_ knobs to twiddle. It took cpufreq a long time to settle down in this area, and typically 'ondemand' was the answer in the end for 99.9% of people. I question the usefulness for the whole multiple governors interface, because in the case of cpuidle there shouldn't be any real trade-off between one algorithm and another afaics? So why can't we just have one, that just 'does the right thing' ? The only differentiator that I can think of would be latency, but that seems to be a) covered in a different tunable, and b) probably wouldn't affect most people enough where it matters.
I'll do a proper code review later, but one thing stuck out like a sore thumb on a quick skim..
> +EXPORT_SYMBOL_GPL(current_driver);
That's a horribly generic name for an exported global.
current_cpuidle_driver maybe?
-- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |