Message-ID: <20110813211142.GA1536@redhat.com>
Date:	Sat, 13 Aug 2011 17:11:42 -0400
From:	Dave Jones <davej@...hat.com>
To:	Jonathan Nieder <jrnieder@...il.com>
Cc:	cpufreq@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Tony Lindgren <tony@...mide.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Mattia Dongili <malattia@...ian.org>
Subject: Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists