On Sat, Aug 13, 2011 at 02:02:46PM -0500, Jonathan Nieder wrote: > Jonathan Nieder wrote: > > > (1) This is still incredibly fragile. What *should* cpufrequtils > > be doing to get the modules it needs? > > > > (2) Using the 3.0 or later kernel with old userspace gives bad > > results (e.g., 30% increase in power consumption for one > > reporter). That's a regression. > > The "30% increase" part was an unrelated bug (i915.i915_enable_rc6=1 > brings power consumption back to normal), for those who were > wondering. :) > > Old userspace automatically loading the wrong cpufreq drivers still > does not seem great to me, though I don't have any great ideas about > how to prevent that (a separate drivers/cpufreq-drivers/ directory > does not sound too appealing). I guess I'd be most interested in how > to fix (1) first. If we have to move stuff again, we could do drivers/cpufreq/x86/ etc.. Even if we do that though, you really want to fix that userspace, because you're right that "load everything and see what sticks" is fragile, and pure luck that it ever did the right thing. What we used to do in Fedora grew more and more complex over time. Here's the last incarnation: http://fpaste.org/uvDb/ As you can see in the start() function, it's pretty hairy, and even that doesn't cover every possible case, which is why it allows a user override in the $DRIVER variable. Messy. Basic thinking is - If AMD64, load powernow-k8 - if that fails to load : try acpi-cpufreq - For everything else : acpi-cpufreq - If acpi-cpufreq fails : p4-clockmod What we're moving towards for Fedora 16 is to change all the drivers to be linked in rather than modular, and rely on link order to do the right thing. It sounds like a step backwards in some ways, towards the 'see what sticks' approach, but the difference here is the link-order specifying the correct order for initialisation. You get none of that with modules. In an ideal world, we'd auto-load the right module on a hotplug event from a cpu, but we're not there yet. I believe Kay is working on that. Over time, 'the right driver' seems to be converging on acpi-cpufreq. There's some patches pending to even move some of the powernow-k8 use-cases to use acpi-cpufreq instead. But modern intel should be using that, (where modern = almost everything since p4, except those that lack P-states) And then there's the 'which governor' mess. I'd really like that to eventually converge so that 'ondemand' is always the right answer. For this to happen, there needs to be no difference between an idle machine running powersave, and ondemand or (harder) a busy machine running performance. (conservative with some work could be just a runtime mode for ondemand). Dave -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
