Re: kernel module options for cpufreq

2008-06-30 Thread Jarod Wilson
On Monday 30 June 2008 05:54:32 am Richard Hughes wrote:
> Right, cheers for your feedback. In view of everybodies comments, what
> about the following:
>
> * Compile _into_ the kernel ondemand, performance, powersave and
> userspace.

Sounds reasonable.

> * Default to performance in the kernel rather than userspace

What's the difference? Both leave the cpu at its max speed all the time, 
unless the cpuspeed daemon gets started up in the userspace case.

> * Build as a module conservative with the view of just fixing ondemand
> if there are any special use-cases that conservative is better at
> * Export the P and C state latency to userspace and let the system
> policy dictate the governor. For instance, even for machines that have a
> long latency for changing P states should be able to use ondemand if we
> want to save maximum power.
>
> How does that sound?

Mostly sane. System policy dictating governor over the ugliness we do in the 
cpuspeed init script would be nice. Even nicer would be if we could outright 
get rid of the initscript (not sure what people who need the cpuspeed daemon 
are to do in that case though).

-- 
Jarod Wilson
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-30 Thread Matthew Garrett
On Mon, Jun 30, 2008 at 09:10:28AM +0200, Adam Tkac wrote:
> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote:
> > * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
> > throttles down to lowest, and is just a hardcoded state
> 
> I don't think removal of powersave governor is good idea. Generally
> ondemand governor does great job but in some cases doesn't. For
> example when I play some films in mplayer ondemand sets frequency to
> max which is not needed, of course.

The same can be achieved by altering 
/sys/devices/system/cpu/*/cpufreq/scaling_max_freq, but it's still 
likely that you're consuming less power when ondemand is setting your 
frequency to max. An idle fast processor consumes less power than an 
active slow one.

> Powersave governor is also good in case that you have bad fan in your
> laptop and you are going to compile some big source. Without powersave
> it is not possible (yes, it really happens :) )

http://lkml.org/lkml/2008/6/16/100

> I think we should preserve ondemand and powersave governors (and
> potentialy others as Dave Jones wrote in this thread). Please don't
> drop them in favour of your project which might be generally better but
> I believe there are cases where current governors are better.

I'm open to indications as to what these are :) Powersave is 
semantically identical to ondemand with scaling_max_freq altered. 
Performance is semantically identical to ondemand with scaling_min_freq 
altered. 

-- 
Matthew Garrett | [EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-30 Thread Richard Hughes
On Mon, 2008-06-30 at 09:10 +0200, Adam Tkac wrote:
> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote:
> > * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
> > throttles down to lowest, and is just a hardcoded state
> 
> I don't think removal of powersave governor is good idea. Generally
> ondemand governor does great job but in some cases doesn't. For
> example when I play some films in mplayer ondemand sets frequency to
> max which is not needed, of course.

Right, so we need to fix ondemand to be cleverer.

> Powersave governor is also good in case that you have bad fan in your
> laptop and you are going to compile some big source. Without powersave
> it is not possible (yes, it really happens :) )

Right, thermal management is similar to power management for the action
but not for the policy. I don't think forcing the lowest speed setting
is the correct way to fix this. If the laptop is running cool, why use
the slowest speed?

> > Matthew Garrett and I are working on a latency profile for power
> > management, and having all these modules potentially loaded is bad.
> > 
> > Comments?
> > 
> 
> I think we should preserve ondemand and powersave governors (and
> potentialy others as Dave Jones wrote in this thread). Please don't
> drop them in favour of your project which might be generally better but
> I believe there are cases where current governors are better.

Right, cheers for your feedback. In view of everybodies comments, what
about the following:

* Compile _into_ the kernel ondemand, performance, powersave and
userspace.
* Default to performance in the kernel rather than userspace
* Build as a module conservative with the view of just fixing ondemand
if there are any special use-cases that conservative is better at
* Export the P and C state latency to userspace and let the system
policy dictate the governor. For instance, even for machines that have a
long latency for changing P states should be able to use ondemand if we
want to save maximum power.

How does that sound?

Richard.


___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-30 Thread Adam Tkac
On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote:
> * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
> throttles down to lowest, and is just a hardcoded state

I don't think removal of powersave governor is good idea. Generally
ondemand governor does great job but in some cases doesn't. For
example when I play some films in mplayer ondemand sets frequency to
max which is not needed, of course.

Powersave governor is also good in case that you have bad fan in your
laptop and you are going to compile some big source. Without powersave
it is not possible (yes, it really happens :) )

> Matthew Garrett and I are working on a latency profile for power
> management, and having all these modules potentially loaded is bad.
> 
> Comments?
> 

I think we should preserve ondemand and powersave governors (and
potentialy others as Dave Jones wrote in this thread). Please don't
drop them in favour of your project which might be generally better but
I believe there are cases where current governors are better.

Adam

-- 
Adam Tkac, Red Hat, Inc.

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-28 Thread Richard Hughes
On Fri, 2008-06-27 at 15:18 -0400, Dave Jones wrote:
> On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote:
>  > At the moment we set:
>  > 
>  > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
>  > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
>  > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
>  > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
>  > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
>  > CONFIG_CPU_FREQ_GOV_POWERSAVE=m
>  > CONFIG_CPU_FREQ_GOV_USERSPACE=y
>  > CONFIG_CPU_FREQ_GOV_ONDEMAND=m
>  > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
>  > 
>  > This is not ideal from a power-saving point of view.
>  > 
>  > In an ideal world we would:
>  > 
>  > * remove CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job
>  > on all workloads
>  > * remove CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace
>  > that needs this sort of control, and if we did, the latency would be
>  > horrible
> 
> needed for the cpuspeed governor

Sure, I might have been a bit hasty in saying _remove_ - I don't really
care about old CPU types but I appreciate lots of people do.

>  > * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
>  > throttles down to lowest, and is just a hardcoded state
>  > * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really
>  > want to be running this on all systems that support it
>  > * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed
>  > to something else by cpuspeed. You really don't want to be using
>  > USERSPACE at all.
> 
> Not all CPUs are capable of running ondemand because of the latency they
> incur during transitions.

Right, isn't the latency exported by the kernel? Surely it's a userspace
decision (policy) if the latency is acceptable? The little tool Matthew
and I prototyped yesterday allows an admin to tweak the latency they
want in the whole system, and depending on the latency acceptable,
different things like ALPM, ASPM and the governor are put in different
modes. Obviously these new switches help in powersaving (lots) but each
add appreciable latency which may be unacceptable. 

>  > Matthew Garrett and I are working on a latency profile for power
>  > management, and having all these modules potentially loaded is bad.
> 
> I don't follow this.  Can you show whatever numbers you have that you're
> basing this on ?

Well, not bad from a speed point of view, bad from a complexity view. If
we compile in ondemand, performance and userspace then we can leave it
up to policy in the system to decide what makes sense. The policy in
userspace can get the latency of the ondemand change and make a decision
on that.

Some of the logic in cpuspeed seems a little complex, and I'm wondering
if we need to be running a service like cpuspeed on a desktop laptop.

Richard.


___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread Dave Jones
On Fri, Jun 27, 2008 at 09:01:34PM +0100, Richard Hughes wrote:
 > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote:
 > > On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes <[EMAIL PROTECTED]>
 > > wrote:
 > > > You really don't want to be using
 > > > USERSPACE at all.
 > > 
 > > seems like cpufreq-applet uses it
 > 
 > Sure, it shouldn't. If you're using userspace for thermal or latency
 > reasons, then a setuid applet is totally the wrong way to achieve both
 > of these :-)
 > 
 > Maybe we can just use these as loadable modules (i.e. not built default)
 > rather than built-in and loaded by default.
 > 
 > DaveJ, do these suggestions seem acceptable?

Having the userspace governor built-in means absolutely nothing in terms of
overhead, until something in userspace actually uses it.

When the cpuspeed init script starts up, the first thing it does is
check if the CPU is on the whitelist for using ondemand, and if so, it
starts up ondemand.  Not a single line of the userspace governor code
gets run in this case.

The only time the above isn't true is when the CPU isn't on that whitelist,
when it's incapable of running ondemand, in which case we need to use..
ta-da... userspace, and then we start the cpuspeed process.

Again, if you're seeing overhead from using userspace, it's due to your
CPU being crap.  There's nothing we can do about it.
Whilst ondemand will load on some of these CPUs, the associated overhead
of switching is very noticable on benchmarks.

Even 'conservative' was too demanding for some of the challenged CPUs.

'crap' here doesn't mean really old stuff too.  Any pre-centrino Intel
CPU, any VIA CPU before Nehemiah generation, all mobile Athlons.

We're using ondemand on all K8's too, but the first generation also
sucked iirc, but we're just sucking it up because a) it makes the
already convoluted startup script even more messy and b) no-one can
remember which stepping/models were affected.

Dave

-- 
http://www.codemonkey.org.uk

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread Bastien Nocera
On Fri, 2008-06-27 at 22:56 +0200, drago01 wrote:
> On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote:
> >> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes <[EMAIL PROTECTED]>
> >> wrote:
> >> > You really don't want to be using
> >> > USERSPACE at all.
> >>
> >> seems like cpufreq-applet uses it
> >
> > Sure, it shouldn't. If you're using userspace for thermal or latency
> > reasons, then a setuid applet is totally the wrong way to achieve both
> > of these :-)
> 
> its not a setuid applet .. something seems to allow non root to do
> this (hal? consolekit? pam? udev? .. dunno)

It currently uses consolehelper to get root. IMO, it shouldn't allow
setting frequencies at all.

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread drago01
On Fri, Jun 27, 2008 at 10:01 PM, Richard Hughes <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote:
>> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes <[EMAIL PROTECTED]>
>> wrote:
>> > You really don't want to be using
>> > USERSPACE at all.
>>
>> seems like cpufreq-applet uses it
>
> Sure, it shouldn't. If you're using userspace for thermal or latency
> reasons, then a setuid applet is totally the wrong way to achieve both
> of these :-)

its not a setuid applet .. something seems to allow non root to do
this (hal? consolekit? pam? udev? .. dunno)

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread Richard Hughes
On Fri, 2008-06-27 at 21:16 +0200, drago01 wrote:
> On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes <[EMAIL PROTECTED]>
> wrote:
> > You really don't want to be using
> > USERSPACE at all.
> 
> seems like cpufreq-applet uses it

Sure, it shouldn't. If you're using userspace for thermal or latency
reasons, then a setuid applet is totally the wrong way to achieve both
of these :-)

Maybe we can just use these as loadable modules (i.e. not built default)
rather than built-in and loaded by default.

DaveJ, do these suggestions seem acceptable?

Richard.


___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread drago01
On Fri, Jun 27, 2008 at 6:13 PM, Richard Hughes <[EMAIL PROTECTED]> wrote:
> You really don't want to be using
> USERSPACE at all.

seems like cpufreq-applet uses it

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread Dave Jones
On Fri, Jun 27, 2008 at 05:13:24PM +0100, Richard Hughes wrote:
 > At the moment we set:
 > 
 > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
 > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
 > # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
 > # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
 > CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
 > CONFIG_CPU_FREQ_GOV_POWERSAVE=m
 > CONFIG_CPU_FREQ_GOV_USERSPACE=y
 > CONFIG_CPU_FREQ_GOV_ONDEMAND=m
 > CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
 > 
 > This is not ideal from a power-saving point of view.
 > 
 > In an ideal world we would:
 > 
 > * remove CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job
 > on all workloads
 > * remove CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace
 > that needs this sort of control, and if we did, the latency would be
 > horrible

needed for the cpuspeed governor

 > * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
 > throttles down to lowest, and is just a hardcoded state
 > * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really
 > want to be running this on all systems that support it
 > * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed
 > to something else by cpuspeed. You really don't want to be using
 > USERSPACE at all.

Not all CPUs are capable of running ondemand because of the latency they
incur during transitions.
 
 > Matthew Garrett and I are working on a latency profile for power
 > management, and having all these modules potentially loaded is bad.

I don't follow this.  Can you show whatever numbers you have that you're
basing this on ?

Dave

-- 
http://www.codemonkey.org.uk

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread John Reiser
Richard Hughes wrote:
> In an ideal world we would:

> * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really
> want to be running this on all systems that support it
> * set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed
> to something else by cpuspeed. You really don't want to be using
> USERSPACE at all.

How can an administrator set a known constant frequency, so that the CPU
might be able to deliver the same amount of work per unit time,
over a span of half an hour?  Some performance measurement and tuning
is much simpler when this is so.

-- 

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel module options for cpufreq

2008-06-27 Thread Arjan van de Ven
On Fri, 27 Jun 2008 17:13:24 +0100
Richard Hughes <[EMAIL PROTECTED]> wrote:

> At the moment we set:
> 
> # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
> # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
> 
> This is not ideal from a power-saving point of view.
> 
> In an ideal world we would:
> 
> * remove CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better
> job on all workloads
> * remove CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in
> userspace that needs this sort of control, and if we did, the latency
> would be horrible
> * remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
> throttles down to lowest, and is just a hardcoded state
> * compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really
> want to be running this on all systems that support it
> * set ONDEMAND or PERFORMANCE to default as USERSPACE is just
> changed to something else by cpuspeed. You really don't want to be
> using USERSPACE at all.
> 
> Matthew Garrett and I are working on a latency profile for power
> management, and having all these modules potentially loaded is bad.
> 
> Comments?
> 

I totally agree with your suggestions.



-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


kernel module options for cpufreq

2008-06-27 Thread Richard Hughes
At the moment we set:

# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

This is not ideal from a power-saving point of view.

In an ideal world we would:

* remove CONFIG_CPU_FREQ_GOV_CONSERVATIVE -- ondemand does a better job
on all workloads
* remove CONFIG_CPU_FREQ_GOV_USERSPACE -- we have nothing in userspace
that needs this sort of control, and if we did, the latency would be
horrible
* remove CONFIG_CPU_FREQ_GOV_POWERSAVE -- ondemand automatically
throttles down to lowest, and is just a hardcoded state
* compile into the kernel CONFIG_CPU_FREQ_GOV_ONDEMAND -- we really
want to be running this on all systems that support it
* set ONDEMAND or PERFORMANCE to default as USERSPACE is just changed
to something else by cpuspeed. You really don't want to be using
USERSPACE at all.

Matthew Garrett and I are working on a latency profile for power
management, and having all these modules potentially loaded is bad.

Comments?

Richard.



___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list