[Pm-utils] [patch commit] [011] POSIXification of pm-utils

Michael Biebl mbiebl at gmail.com
Sun Jan 27 19:38:32 PST 2008


2008/1/28, Victor Lowther <victor.lowther at gmail.com>:
> On Jan 27, 2008 9:26 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> > 2008/1/28, Victor Lowther <victor.lowther at gmail.com>:
> > > On Jan 27, 2008 9:04 PM, Michael Biebl <mbiebl at gmail.com> wrote:
> >
> >
> > >
> > > The only reason I changed the fall back to performance is that on a
> > > vanilla kernel with cpufreq enabled it is compiled in, and the others
> > > are not even selected -- CPU speed is not the limiting factor.
> >
> > Right, that's why I think TEMPORARY_CPUFREQ_GOVERNOR should be set to
> > performance by default (as it's the safest bet). I don't see a good
> > reason to make userspace the default governor for suspend/hibernate.
> > Don't you agree?
>
> It does not matter what TEMPORARY_CPUFREQ_GOVERNOR is, as long as it
> is valid and known to not break suspend/resume.  The change I made
> only applies when it is not valid, and I think that the distros should
> worry about the setting of the environment variable, not us.  If
> userspace is present it is a good as any other.

Actually, I think the current logic is broken. If we can't find
TEMPORARY_CPUFREQ_GOVERNOR in
/sys/devices/system/cpu/cpu$x/cpufreq/scaling_governor, we fall back
uncoditionally to userspace (or with your patch performance) and it's
possible that this fallback governor is not available. The best bet in
that case is simply to not change the governor at all.

And again, a better default governor for TEMPORARY_CPUFREQ_GOVERNOR
would be performance imho.

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


More information about the Pm-utils mailing list