[PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Felix Braun]

Hi there,

I recently bought a laptop which is reported by Intel's CPUid tool as a
Celeron-M 373. Linux identifies this processor like this (/proc/cpuinfo)

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 13
model name	: Intel(R) Celeron(R) M processor         1.00GHz
stepping	: 8
cpu MHz		: 999.915
cache size	: 512 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe
bogomips	: 2001.80

I would like to use CPU frequency scaling to increase my battery life. As
this processor can't do EnhancedSpeedStep (Celerons seem to be unable to
do so in general) I've been using the p4-clockmod driver.

However, as my processor is based on the Dothan architecture (cpu_family
6, model 13), I get a warning that I should use speedstep_centrino
instead. This warning is misleading because I have a Celeron. Therefore, I
suggest the following patch to silence this warning.

================
We only have a Pentium-M (Dothan) if the cache size is 2048K. Don't print
the warning for Dothan-based Celeron-M processors which have a cache size
of 512K or 1024K.

Signed-off-by: Felix Braun <Felix.Braun@mail.McGill.ca>

--- a/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c  2005-12-01 23:47:01 +0100
+++ b/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c  2005-12-01 23:50:11 +0100
@@ -171,7 +171,8 @@
                return speedstep_get_processor_frequency(SPEEDSTEP_PROCESSOR_PM);
        }
 
-       if ((c->x86 == 0x06) && (c->x86_model == 0x0D)) {
+       if ((c->x86 == 0x06) && (c->x86_model == 0x0D)
+                       && (c->x86_cache_size == 2048)) {
                /* Pentium M (Dothan) */
                printk(KERN_WARNING PFX "Warning: Pentium M detected. "
                       "The speedstep_centrino module offers voltage scaling"

RE: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of Felix Braun
>Sent: Friday, December 02, 2005 5:57 AM
>To: CPUFreq@lists.linux.org.uk
>Subject: [PATCH 2.6.14] cpufreq: don't suggest 
>speedstep-centrino for Dothan-based Celeron-M processors
>
>Hi there,
>
>I recently bought a laptop which is reported by Intel's CPUid tool as a
>Celeron-M 373. Linux identifies this processor like this 
>(/proc/cpuinfo)
>
>processor	: 0
>vendor_id	: GenuineIntel
>cpu family	: 6
>model		: 13
>model name	: Intel(R) Celeron(R) M processor         1.00GHz
>stepping	: 8
>cpu MHz		: 999.915
>cache size	: 512 KB
>fdiv_bug	: no
>hlt_bug		: no
>f00f_bug	: no
>coma_bug	: no
>fpu		: yes
>fpu_exception	: yes
>cpuid level	: 2
>wp		: yes
>flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe
>bogomips	: 2001.80
>
>I would like to use CPU frequency scaling to increase my 
>battery life. As
>this processor can't do EnhancedSpeedStep (Celerons seem to be 
>unable to
>do so in general) I've been using the p4-clockmod driver.
>

I think from user perspectibe, P4-clockmod is most confusing driver
ever. P4-clockmod will only do the duty-cycle based throttling and will
not save any significant power. In fact, CPU may end up consuming more
power than without it for a constant amount of unit-work (Dominik has
patiently explained it quite a few times on this list). It will only
help in thermal conditions and ACPI throttling driver should handle that
anyway. Given this: I vote for removing p4-clockmod altogether from
cpufreq drivers. Dave, Dominik: do you agree?

Thanks,
Venki

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Felix Braun]

On Fri, 02 Dec 2005 06:26:52 -0800 "Pallipadi, Venkatesh"
<venkatesh.pallipadi@intel.com> wrote:

> P4-clockmod will only do the duty-cycle based throttling and will
> not save any significant power. In fact, CPU may end up consuming more
> power than without it [...]. It will only help in thermal conditions
> and ACPI throttling driver should handle that anyway.

By "ACPI throttling driver" do you mean arch/i386/.../acpi_cpufreq? That
driver didn't work for me :-( I get a error: no such device when I try to
load it as a module. I haven't looked into that yet.

Anyway, thanks a lot for the information

Felix

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Bruno Ducrot]

On Fri, Dec 02, 2005 at 06:26:52AM -0800, Pallipadi, Venkatesh wrote:
> 
> I think from user perspectibe, P4-clockmod is most confusing driver
> ever. P4-clockmod will only do the duty-cycle based throttling and will
> not save any significant power. In fact, CPU may end up consuming more
> power than without it for a constant amount of unit-work (Dominik has
> patiently explained it quite a few times on this list). It will only
> help in thermal conditions and ACPI throttling driver should handle that
> anyway. Given this: I vote for removing p4-clockmod altogether from
> cpufreq drivers. Dave, Dominik: do you agree?

-1

There is an infrastructure in order to cool the processor with
cpufreq.  Doing what you propose disallow people with such
configurations to use ACPI passive cooling.

I propose instead that we use some sort of flags such
that only cpufreq driver which are able to scale voltages, or
knowns to ofer good power savings, use the policy/governor
stuff.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

RE: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Bruno Ducrot [mailto:ducrot@poupinou.org] 
>Sent: Friday, December 02, 2005 7:04 AM
>To: Pallipadi, Venkatesh
>Cc: Felix Braun; CPUFreq@lists.linux.org.uk; davej@redhat.com; 
>Dominik Brodowski
>Subject: Re: [PATCH 2.6.14] cpufreq: don't suggest 
>speedstep-centrino for Dothan-based Celeron-M processors
>
>On Fri, Dec 02, 2005 at 06:26:52AM -0800, Pallipadi, Venkatesh wrote:
>> 
>> I think from user perspectibe, P4-clockmod is most confusing driver
>> ever. P4-clockmod will only do the duty-cycle based 
>throttling and will
>> not save any significant power. In fact, CPU may end up 
>consuming more
>> power than without it for a constant amount of unit-work (Dominik has
>> patiently explained it quite a few times on this list). It will only
>> help in thermal conditions and ACPI throttling driver should 
>handle that
>> anyway. Given this: I vote for removing p4-clockmod altogether from
>> cpufreq drivers. Dave, Dominik: do you agree?
>
>-1
>
>There is an infrastructure in order to cool the processor with
>cpufreq.  Doing what you propose disallow people with such
>configurations to use ACPI passive cooling.
>

I agree with the intent of providing infrastructure for cooling.
But, doing it along with the other cpufreq drivers that save power 
is not good IMHO.

I mean, 
- For end user it appears as if another way to change the frequency 
to save power.
- Support for cooling doesn't work when CPU also supports freq/voltage 
scaling. Say a Enhanced Speedstep capable P4 CPU can still do throttling

for cooling. But, current cpufreq doesn't support that.
- Cooling driver should ideally be triggerred by thermal events and that

doesn't seem to happen either.

>I propose instead that we use some sort of flags such
>that only cpufreq driver which are able to scale voltages, or
>knowns to ofer good power savings, use the policy/governor
>stuff.

I was thinking of a cpufreq clone that does similar things to idle-state

(C-state) as cpufreq does to frequency/voltage (P-state) states.
Probably we 
need to have another similar set of APIs for cooling (T-state) as well.
Are 
there any other low-level drivers that provide P4-clockmod kind of
cooling 
support. Clubbing them together under a different umbrella, we may be
able to 
separate them from the power-saving frequency change drivers.

For short term though, atleast there need to be some big Red flag
against 
using p4-clockmod for powersave purposes. Having that info in CONFIG
help 
doesn't seem to be working.

Thanks,
Venki

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Felix Braun]

On Fri, 02 Dec 2005 08:58:12 -0800 "Pallipadi, Venkatesh"
<venkatesh.pallipadi@intel.com> wrote:


> For short term though, atleast there need to be some big Red flag
> against using p4-clockmod for powersave purposes. Having that info in CONFIG
> help doesn't seem to be working.

I didn't see any such information in CONFIG_HELP. Still, I'm happy to use
it for thermal management too :-)

Bye
Felix

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Bruno Ducrot]

On Fri, Dec 02, 2005 at 08:58:12AM -0800, Pallipadi, Venkatesh wrote:
>  
> 
> >-----Original Message-----
> >From: Bruno Ducrot [mailto:ducrot@poupinou.org] 
> >Sent: Friday, December 02, 2005 7:04 AM
> >To: Pallipadi, Venkatesh
> >Cc: Felix Braun; CPUFreq@lists.linux.org.uk; davej@redhat.com; 
> >Dominik Brodowski
> >Subject: Re: [PATCH 2.6.14] cpufreq: don't suggest 
> >speedstep-centrino for Dothan-based Celeron-M processors
> >
> >On Fri, Dec 02, 2005 at 06:26:52AM -0800, Pallipadi, Venkatesh wrote:
> >> 
> >> I think from user perspectibe, P4-clockmod is most confusing driver
> >> ever. P4-clockmod will only do the duty-cycle based 
> >throttling and will
> >> not save any significant power. In fact, CPU may end up 
> >consuming more
> >> power than without it for a constant amount of unit-work (Dominik has
> >> patiently explained it quite a few times on this list). It will only
> >> help in thermal conditions and ACPI throttling driver should 
> >handle that
> >> anyway. Given this: I vote for removing p4-clockmod altogether from
> >> cpufreq drivers. Dave, Dominik: do you agree?
> >
> >-1
> >
> >There is an infrastructure in order to cool the processor with
> >cpufreq.  Doing what you propose disallow people with such
> >configurations to use ACPI passive cooling.
> >
> 
> I agree with the intent of providing infrastructure for cooling.
> But, doing it along with the other cpufreq drivers that save power 
> is not good IMHO.
> 
> I mean, 
> - For end user it appears as if another way to change the frequency 
> to save power.

Indeed.  That the main issue in fact.

> - Support for cooling doesn't work when CPU also supports freq/voltage 
> scaling. Say a Enhanced Speedstep capable P4 CPU can still do throttling

We use cpufreq already if present, then acpi_throttle.

> for cooling. But, current cpufreq doesn't support that.
> - Cooling driver should ideally be triggerred by thermal events and that
> doesn't seem to happen either.

I think you should look at linux/drivers/acpi/processor_thermal.c then.

> >I propose instead that we use some sort of flags such
> >that only cpufreq driver which are able to scale voltages, or
> >knowns to ofer good power savings, use the policy/governor
> >stuff.
> 
> I was thinking of a cpufreq clone that does similar things to idle-state
> 
> (C-state) as cpufreq does to frequency/voltage (P-state) states.
> Probably we 
> need to have another similar set of APIs for cooling (T-state) as well.
> Are 
> there any other low-level drivers that provide P4-clockmod kind of
> cooling 
> support. Clubbing them together under a different umbrella, we may be
> able to 
> separate them from the power-saving frequency change drivers.
> 
> For short term though, atleast there need to be some big Red flag
> against 
> using p4-clockmod for powersave purposes. Having that info in CONFIG
> help 
> doesn't seem to be working.
> 
> Thanks,
> Venki
> 
> _______________________________________________
> Cpufreq mailing list
> Cpufreq@lists.linux.org.uk
> http://lists.linux.org.uk/mailman/listinfo/cpufreq

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

RE: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Bruno Ducrot [mailto:ducrot@poupinou.org] 
>> - Support for cooling doesn't work when CPU also supports 
>freq/voltage 
>> scaling. Say a Enhanced Speedstep capable P4 CPU can still 
>do throttling
>
>We use cpufreq already if present, then acpi_throttle.
>
>> for cooling. But, current cpufreq doesn't support that.
>> - Cooling driver should ideally be triggerred by thermal 
>events and that
>> doesn't seem to happen either.
>
>I think you should look at linux/drivers/acpi/processor_thermal.c then.
>

I understand acpi_throttle and processor_thermal doing it. But,
p4-clockmod, meant for cooling should actual run like acpi_throttle and
get triggered more like throttle rather than powersaving frequency
drivers. Right? 
Also, if throttling information is not there in ACPI, even then P4
clockmod can potentially be used as a replacement for acpi_throttle and
coexist with say acpi-cpufreq.

Thanks,
Venki

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Dominik Brodowski]

Hi,

On Fri, Dec 02, 2005 at 01:19:27PM -0800, Pallipadi, Venkatesh wrote:
> I understand acpi_throttle and processor_thermal doing it. But,
> p4-clockmod, meant for cooling should actual run like acpi_throttle and
> get triggered more like throttle rather than powersaving frequency
> drivers. Right? 
> Also, if throttling information is not there in ACPI, even then P4
> clockmod can potentially be used as a replacement for acpi_throttle and
> coexist with say acpi-cpufreq.

Yes, exactly. In my TODO list for cpufreq, I still have this entry:
- [core] evaluate use of > 1 drivers at one time (CPUFREQ_THROTTLING, 
        CPUFREQ_SCALING)

However, as I'm too busy at the moment to tackle this issue, it'd be great
if someone else could handle this one ;)

Thanks,
	Dominik

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Bruno Ducrot]

On Sun, Dec 04, 2005 at 05:46:20PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Fri, Dec 02, 2005 at 01:19:27PM -0800, Pallipadi, Venkatesh wrote:
> > I understand acpi_throttle and processor_thermal doing it. But,
> > p4-clockmod, meant for cooling should actual run like acpi_throttle and
> > get triggered more like throttle rather than powersaving frequency
> > drivers. Right? 
> > Also, if throttling information is not there in ACPI, even then P4
> > clockmod can potentially be used as a replacement for acpi_throttle and
> > coexist with say acpi-cpufreq.
> 
> Yes, exactly. In my TODO list for cpufreq, I still have this entry:
> - [core] evaluate use of > 1 drivers at one time (CPUFREQ_THROTTLING, 
>         CPUFREQ_SCALING)

Yes, that's what I had in mind.  But maybe we could at first make the
distinction before being able to load more than one driver?

> 
> However, as I'm too busy at the moment to tackle this issue, it'd be great
> if someone else could handle this one ;)

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Dominik Brodowski]

Hi,

On Mon, Dec 05, 2005 at 12:00:12PM +0100, Bruno Ducrot wrote:
> > Yes, exactly. In my TODO list for cpufreq, I still have this entry:
> > - [core] evaluate use of > 1 drivers at one time (CPUFREQ_THROTTLING, 
> >         CPUFREQ_SCALING)
> 
> Yes, that's what I had in mind.  But maybe we could at first make the
> distinction before being able to load more than one driver?

Yes, sure. However, only on the x86 I'm quite confident that the throttling
state is equivalent to the idle state, and therefore doesn't offer
_additional_ power savings (besides the effect discussed by Dave yesterday)
if the CPU load is lower than (1 - throttling_rate), IMO.

CPUFREQ_SCALING:
	acpi-cpufreq
	elanfreq
	powernow-k{6,7,8}
	speedstep-{smi,ich,centrino}
	longrun
	longhaul

CPUFREQ_THROTTLING:
	p4-clockmod
	gx-suspmod

The other architectures I'm not so familiar with, so this list is x86 only
at the moment.

	Dominik

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Bruno Ducrot]

On Tue, Dec 06, 2005 at 07:01:49AM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Mon, Dec 05, 2005 at 12:00:12PM +0100, Bruno Ducrot wrote:
> > > Yes, exactly. In my TODO list for cpufreq, I still have this entry:
> > > - [core] evaluate use of > 1 drivers at one time (CPUFREQ_THROTTLING, 
> > >         CPUFREQ_SCALING)
> > 
> > Yes, that's what I had in mind.  But maybe we could at first make the
> > distinction before being able to load more than one driver?
> 
> Yes, sure. However, only on the x86 I'm quite confident that the throttling
> state is equivalent to the idle state, and therefore doesn't offer
> _additional_ power savings (besides the effect discussed by Dave yesterday)
> if the CPU load is lower than (1 - throttling_rate), IMO.
> 
> CPUFREQ_SCALING:
> 	acpi-cpufreq
> 	elanfreq
> 	powernow-k{6,7,8}
> 	speedstep-{smi,ich,centrino}
> 	longrun
> 	longhaul
> 
> CPUFREQ_THROTTLING:
> 	p4-clockmod
> 	gx-suspmod

Well, there is the cpufreq-nvidia2 driver.  I'm pretty sure that one does not
fit there.  I don't know what are exactly the benefits so far.

> The other architectures I'm not so familiar with, so this list is x86 only
> at the moment.

Erm yes.  Can't help here.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [PATCH 2.6.14] cpufreq: don't suggest speedstep-centrino for Dothan-based Celeron-M processors

[Dominik Brodowski]

Hi,

On Tue, Dec 06, 2005 at 11:03:24AM +0100, Bruno Ducrot wrote:
> Well, there is the cpufreq-nvidia2 driver.  I'm pretty sure that one does not
> fit there.  I don't know what are exactly the benefits so far.

It modifies the FSB, so it scales the CPU frequency => CPUFREQ_SCALING

	Dominik