* speedstep-centrino on dothan
@ 2005-07-06 9:22 st3
2005-07-06 14:06 ` Dominik Brodowski
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: st3 @ 2005-07-06 9:22 UTC (permalink / raw)
To: linux-kernel
Currently, the speedstep-centrino support has built-in frequency/voltage
pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
BIOS ACPI.
But ACPI encoding may not be available or not reliable, so why shouldn't we
provide built-in tables for Dothan CPUs, too? Intel has released this
datasheet:
http://www.intel.com/design/mobile/datashts/302189.htm
with frequency/voltage pairs for every version of Dothan CPUs.
Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest
frequency at which the CPU can be set safely is not the 600MHz given in
datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see
datasheet for more details) set to 0.908V.
I can provide a patch, let me know.
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 9:22 speedstep-centrino on dothan st3
@ 2005-07-06 14:06 ` Dominik Brodowski
2005-07-06 19:45 ` st3
2005-07-06 16:30 ` Pedro Ramalhais
2005-07-06 19:58 ` Bill Davidsen
2 siblings, 1 reply; 22+ messages in thread
From: Dominik Brodowski @ 2005-07-06 14:06 UTC (permalink / raw)
To: st3; +Cc: linux-kernel
Hi,
On Wed, Jul 06, 2005 at 11:22:02AM +0200, st3@riseup.net wrote:
> Currently, the speedstep-centrino support has built-in frequency/voltage
> pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
> BIOS ACPI.
>
> But ACPI encoding may not be available or not reliable, so why shouldn't we
> provide built-in tables for Dothan CPUs, too? Intel has released this
> datasheet:
>
> http://www.intel.com/design/mobile/datashts/302189.htm
>
> with frequency/voltage pairs for every version of Dothan CPUs.
However, it is not known which one of VID#A, VID#B, VID#C or VID#D is to be
used on a specific system.
Dominik
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 9:22 speedstep-centrino on dothan st3
2005-07-06 14:06 ` Dominik Brodowski
@ 2005-07-06 16:30 ` Pedro Ramalhais
2005-07-06 19:58 ` Bill Davidsen
2 siblings, 0 replies; 22+ messages in thread
From: Pedro Ramalhais @ 2005-07-06 16:30 UTC (permalink / raw)
To: linux-kernel
st3@riseup.net wrote:
> Currently, the speedstep-centrino support has built-in frequency/voltage
> pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
> BIOS ACPI.
>
> But ACPI encoding may not be available or not reliable, so why shouldn't we
> provide built-in tables for Dothan CPUs, too? Intel has released this
> datasheet:
>
> http://www.intel.com/design/mobile/datashts/302189.htm
>
> with frequency/voltage pairs for every version of Dothan CPUs.
>
> Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest
> frequency at which the CPU can be set safely is not the 600MHz given in
> datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see
> datasheet for more details) set to 0.908V.
>
> I can provide a patch, let me know.
>
>
> --
> ciao
> st3
>
I looked into it 2 weeks ago, and i couldn't find a complete voltage
table for the Dothan C1 stepping (which my laptop has). I only found a
table with (IIRC) the max and min voltages for the max and min
frequencies. I also didn't understand the meaning of the different
VID#{A,B,C,D,E} values. Are these voltages related to the quality of the
power supply, or the quality of the processor? How do we know which one
to choose?
Regards,
--
Pedro Ramalhais
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 14:06 ` Dominik Brodowski
@ 2005-07-06 19:45 ` st3
0 siblings, 0 replies; 22+ messages in thread
From: st3 @ 2005-07-06 19:45 UTC (permalink / raw)
To: linux-kernel
On Wed, 6 Jul 2005 16:06:53 +0200
Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> Hi,
>
> On Wed, Jul 06, 2005 at 11:22:02AM +0200, st3@riseup.net wrote:
> > Currently, the speedstep-centrino support has built-in frequency/voltage
> > pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
> > BIOS ACPI.
> >
> > But ACPI encoding may not be available or not reliable, so why shouldn't we
> > provide built-in tables for Dothan CPUs, too? Intel has released this
> > datasheet:
> >
> > http://www.intel.com/design/mobile/datashts/302189.htm
> >
> > with frequency/voltage pairs for every version of Dothan CPUs.
>
> However, it is not known which one of VID#A, VID#B, VID#C or VID#D is to be
> used on a specific system.
Ok, so we could patch it in order to use acpi if available, and else use,
say, VID#C (every different VID is suitable for any system I tested so far;
moreover, voltages are very similar).
The safe choice is VID#A, the best one is VID#D =)
Another option: add a module_param for that, and make it configurable in
Kconfig whether to use ACPI tables or select between different VID profiles
through the parameter (not just for Banias, as of current version),
defaulting to VID#A.
anyway I will:
1) look for more specifications from Intel;
2) check VID setup on different systems (who can say that OEMs really use
them differently?).
Then, i found out that running CPU (in my case, Dothan 715) at 400MHz saves
lot of battery, really (on a Toshiba Satellite A50 with standard battery,
idling, 6h20 vs. 5h at 600MHz): it would be very nice to add support
for these frequencies to speedstep-centrino.
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 9:22 speedstep-centrino on dothan st3
2005-07-06 14:06 ` Dominik Brodowski
2005-07-06 16:30 ` Pedro Ramalhais
@ 2005-07-06 19:58 ` Bill Davidsen
2005-07-06 21:11 ` Dave Jones
2005-07-07 21:59 ` st3
2 siblings, 2 replies; 22+ messages in thread
From: Bill Davidsen @ 2005-07-06 19:58 UTC (permalink / raw)
To: linux-kernel
st3@riseup.net wrote:
> Currently, the speedstep-centrino support has built-in frequency/voltage
> pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
> BIOS ACPI.
>
> But ACPI encoding may not be available or not reliable, so why shouldn't we
> provide built-in tables for Dothan CPUs, too? Intel has released this
> datasheet:
>
> http://www.intel.com/design/mobile/datashts/302189.htm
>
> with frequency/voltage pairs for every version of Dothan CPUs.
>
> Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest
> frequency at which the CPU can be set safely is not the 600MHz given in
> datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see
> datasheet for more details) set to 0.908V.
>
> I can provide a patch, let me know.
Slower is better, and not depending on ACPI for anything which can be
gotten elsewhere is a good thing. Sounds like a good idea to me.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 19:58 ` Bill Davidsen
@ 2005-07-06 21:11 ` Dave Jones
2005-07-06 21:55 ` st3
2005-07-07 21:59 ` st3
1 sibling, 1 reply; 22+ messages in thread
From: Dave Jones @ 2005-07-06 21:11 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel
On Wed, Jul 06, 2005 at 03:58:53PM -0400, Bill Davidsen wrote:
> st3@riseup.net wrote:
> >Currently, the speedstep-centrino support has built-in frequency/voltage
> >pairs only for Banias CPUs. For Dothan CPUs, these tables are read from
> >BIOS ACPI.
> >
> >But ACPI encoding may not be available or not reliable, so why shouldn't we
> >provide built-in tables for Dothan CPUs, too? Intel has released this
> >datasheet:
> >
> >http://www.intel.com/design/mobile/datashts/302189.htm
> >
> >with frequency/voltage pairs for every version of Dothan CPUs.
> >
> >Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest
> >frequency at which the CPU can be set safely is not the 600MHz given in
> >datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see
> >datasheet for more details) set to 0.908V.
> >
> >I can provide a patch, let me know.
>
> Slower is better, and not depending on ACPI for anything which can be
> gotten elsewhere is a good thing. Sounds like a good idea to me.
This can't be done safely through any other means than ACPI right now.
It needs to know intimate things about which VID line is wired to what,
which is board specific.
Dave
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 21:11 ` Dave Jones
@ 2005-07-06 21:55 ` st3
2005-07-07 20:00 ` enhanced intel speedstep feature was " st3
0 siblings, 1 reply; 22+ messages in thread
From: st3 @ 2005-07-06 21:55 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
On Wed, 6 Jul 2005 17:11:59 -0400
Dave Jones <davej@redhat.com> wrote:
> This can't be done safely through any other means than ACPI right now.
> It needs to know intimate things about which VID line is wired to what,
> which is board specific.
I don't think it's related to 'which VID line is wired to what': this isn't
board specific, as it's given in datasheets provided by Intel (6 pins, etc).
The only issue is that there are four different versions of Dothan CPUs for
A1, A2, B0, B1, C0 steppings. There is only one version for C1 stepping. For
those different versions, Intel provides different typical voltage ranges.
For example, in read a post by Michael Clark in which he claims his IBM T42
has VID#A version of Dothan 745. I read ACPI tables on my laptop (Toshiba
Satellite A50, with Dothan 715) and I saw I got a VID#A version of Dothan
715 (is there somebody around with some other versions?).
Additionally, for lower frequencies VID#{A,B,C,D,E} voltages are the same.
So I ask: wouldn't it be good to find a way to add some lower frequencies,
while still reading ACPI tables for the other ones? Or to make profiles
configurable as a module parameter (as boot)? My problem isn't really ACPI,
but rather that one can't use lower and very useful frequencies.
Moreover, we could provide built-in tables for C1 stepping.
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-06 21:55 ` st3
@ 2005-07-07 20:00 ` st3
2005-07-07 20:06 ` Dave Jones
0 siblings, 1 reply; 22+ messages in thread
From: st3 @ 2005-07-07 20:00 UTC (permalink / raw)
To: linux-kernel, cpufreq
Pedro Ramalhais found another interesting thing in:
ftp://download.intel.com/design/Pentium4/manuals/25366816.pdf
that's the IA32_CLOCK_MODULATION (still called
MSR_IA32_THERM_CONTROL in include/asm-i386/msr.h, and I think this would
need a fix) register, that let set a reduced CPU duty cycle. So just today I
coded something to use it.
Just add to speedstep-centrino.c:
[yes I know, this isn't the Right Coding Style, but it's just to give an
idea of the whole thing]
static int sccm_level = 0;
module_param(sccm_level, uint, 0644);
MODULE_PARM_DESC(sccm_level, "Software Controlled Clock Modulation level: 0
for disabling, 7 for 12.5\% duty cycle");
in the first part, right after the third #define
and this function after centrino_target():
static int centrino_target_sccm ()
{
unsigned int msr, h;
rdmsr(MSR_IA32_THERM_CONTROL, msr, h);
msr &= (0<<1); msr &= (0<<2); msr &= (0<<3);
switch (sccm_level) {
case 0:
msr &= (0<<4);
case 1:
msr |= (1<<4); msr |= (1<<3); msr |= (1<<2);
msr |= (1<<1); break;
case 2:
msr |= (i<<4); msr |= (1<<3); msr |= (1<<2); break;
case 3:
msr |= (1<<4); msr |= (1<<3); msr |= (1<<1); break;
case 4:
msr |= (1<<4); msr |= (1<<3); break;
case 5:
msr |= (1<<4); msr |= (1<<2); msr |= (1<<1); break;
case 6:
msr |= (1<<4); msr |= (1<<2); break;
case 7:
msr |= (1<<4); msr |= (1<<1); break;
}
wrmsr (MSR_IA32_THERM_CONTROL, msr, h);
}
Then you'll just have to insmod speedstep-centrino.ko sccm_level=x, where x
can be 0 to disable software cycle control modulation, 1 to enable a
reduced duty cycle of 87.5%, 7 to enable a duty cycle of 12.5% and so on.
Enabling, say, a duty cycle of 12.5% means that the CPU chip will be driven
by clock just one time every eight, thus reducing power consumption and
temperature (and it speeds down dramatically the CPU, too =).
I tested it so far on my Pentium M Dothan 715 and on a Dothan 725.
What do you think, could this be useful? I could provide a patch or a
stand-alone module. Should I write an interface to sysfs?
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 20:00 ` enhanced intel speedstep feature was " st3
@ 2005-07-07 20:06 ` Dave Jones
2005-07-07 20:22 ` st3
0 siblings, 1 reply; 22+ messages in thread
From: Dave Jones @ 2005-07-07 20:06 UTC (permalink / raw)
To: st3; +Cc: linux-kernel, cpufreq
On Thu, Jul 07, 2005 at 10:00:27PM +0200, st3@riseup.net wrote:
> Enabling, say, a duty cycle of 12.5% means that the CPU chip will be driven
> by clock just one time every eight, thus reducing power consumption and
> temperature (and it speeds down dramatically the CPU, too =).
>
> I tested it so far on my Pentium M Dothan 715 and on a Dothan 725.
>
> What do you think, could this be useful? I could provide a patch or a
> stand-alone module. Should I write an interface to sysfs?
You just reinvented the p4-clockmod driver :-)
This hasn't been seen to save any power whatsoever that I've seen.
I've heard a few reports that it reduces heat for a few folks, but
betting on it increasing your battery life is probably a push.
Dave
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 20:06 ` Dave Jones
@ 2005-07-07 20:22 ` st3
2005-07-07 20:40 ` Dave Jones
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: st3 @ 2005-07-07 20:22 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel, cpufreq
On Thu, 7 Jul 2005 16:06:48 -0400
Dave Jones <davej@redhat.com> wrote:
> On Thu, Jul 07, 2005 at 10:00:27PM +0200, st3@riseup.net wrote:
> > Enabling, say, a duty cycle of 12.5% means that the CPU chip will be driven
> > by clock just one time every eight, thus reducing power consumption and
> > temperature (and it speeds down dramatically the CPU, too =).
> >
> > I tested it so far on my Pentium M Dothan 715 and on a Dothan 725.
> >
> > What do you think, could this be useful? I could provide a patch or a
> > stand-alone module. Should I write an interface to sysfs?
>
> You just reinvented the p4-clockmod driver :-)
Oops. =)
> This hasn't been seen to save any power whatsoever that I've seen.
It drops down power rating by 1500-1800mW on my Toshiba Satellite A50
while idling at 400MHz.
> I've heard a few reports that it reduces heat for a few folks, but
> betting on it increasing your battery life is probably a push.
Just a latest question: can be p4-clockmod used together with
speedstep-centrino? If not, would it make any sense to patch
speedstep-centrino to use this feature too?
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 20:22 ` st3
@ 2005-07-07 20:40 ` Dave Jones
2005-07-07 20:51 ` Joseph Pingenot
2005-07-07 21:10 ` Dominik Brodowski
2 siblings, 0 replies; 22+ messages in thread
From: Dave Jones @ 2005-07-07 20:40 UTC (permalink / raw)
To: st3; +Cc: linux-kernel, cpufreq
On Thu, Jul 07, 2005 at 10:22:25PM +0200, st3@riseup.net wrote:
> > This hasn't been seen to save any power whatsoever that I've seen.
>
> It drops down power rating by 1500-1800mW on my Toshiba Satellite A50
> while idling at 400MHz.
>
> > I've heard a few reports that it reduces heat for a few folks, but
> > betting on it increasing your battery life is probably a push.
>
> Just a latest question: can be p4-clockmod used together with
> speedstep-centrino? If not, would it make any sense to patch
> speedstep-centrino to use this feature too?
There was some discussion on cpufreq list long ago to make cpufreq
drivers stackable, but it's never been a high enough priority for
anyone to actually do the work.
Dave
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 20:22 ` st3
2005-07-07 20:40 ` Dave Jones
@ 2005-07-07 20:51 ` Joseph Pingenot
2005-07-07 21:08 ` Dominik Brodowski
2005-07-07 21:10 ` Dominik Brodowski
2 siblings, 1 reply; 22+ messages in thread
From: Joseph Pingenot @ 2005-07-07 20:51 UTC (permalink / raw)
To: st3; +Cc: Dave Jones, linux-kernel, cpufreq
>Just a latest question: can be p4-clockmod used together with
>speedstep-centrino? If not, would it make any sense to patch
>speedstep-centrino to use this feature too?
I'm a little confused. How is this different from the ACPI CPU throttling
states (/proc/acpi/processor/CPUn/limit to set, throttling to see all
T-states available)?
On my 1.5-year-old Pentium-M, frequency scaling and T-states are different
beasties, and act entirely differently. I'm currently in the process of
rewriting my governor's brain to deal with the two more intelligently.
-Joseph
--
Joseph===============================================trelane@digitasaru.net
Graduate Student in Physics, Freelance Free Software Developer
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 20:51 ` Joseph Pingenot
@ 2005-07-07 21:08 ` Dominik Brodowski
2005-07-07 21:34 ` Joseph Pingenot
0 siblings, 1 reply; 22+ messages in thread
From: Dominik Brodowski @ 2005-07-07 21:08 UTC (permalink / raw)
To: st3, Dave Jones, linux-kernel, cpufreq
On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote:
> >Just a latest question: can be p4-clockmod used together with
> >speedstep-centrino? If not, would it make any sense to patch
> >speedstep-centrino to use this feature too?
>
> I'm a little confused. How is this different from the ACPI CPU throttling
> states (/proc/acpi/processor/CPUn/limit to set, throttling to see all
> T-states available)?
T-states _tend_ to be utilized using chipset logic, while p4-clockmod is
done in-CPU.
> On my 1.5-year-old Pentium-M, frequency scaling and T-states are different
> beasties, and act entirely differently. I'm currently in the process of
> rewriting my governor's brain to deal with the two more intelligently.
In your case, I would care about throttling. In very most cases it actually
increases energy consumption, as the state being entered is technically the
same to ACPI C2 (IIRC), so it is only "forced" idling and only useful if
"forced" idling is needed to not need active cooling.
Dominik
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 20:22 ` st3
2005-07-07 20:40 ` Dave Jones
2005-07-07 20:51 ` Joseph Pingenot
@ 2005-07-07 21:10 ` Dominik Brodowski
2005-07-07 21:22 ` st3
2 siblings, 1 reply; 22+ messages in thread
From: Dominik Brodowski @ 2005-07-07 21:10 UTC (permalink / raw)
To: st3; +Cc: Dave Jones, cpufreq, linux-kernel
On Thu, Jul 07, 2005 at 10:22:25PM +0200, st3@riseup.net wrote:
> > This hasn't been seen to save any power whatsoever that I've seen.
>
> It drops down power rating by 1500-1800mW on my Toshiba Satellite A50
> while idling at 400MHz.
Do you use ACPI-based idling? If so, in which state is the CPU in (cat
/proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else
you wouldn't need the table-based approach) or that the ACPI-based idling is
broken on your notebook; as then the Linux idle handler only makes use of
"hlt" (IIRC), that is ACPI C1, while throttling "forces" ACPI C2 (again
IIRC).
Dominik
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 21:10 ` Dominik Brodowski
@ 2005-07-07 21:22 ` st3
2005-07-07 21:29 ` Dominik Brodowski
0 siblings, 1 reply; 22+ messages in thread
From: st3 @ 2005-07-07 21:22 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Dave Jones, cpufreq, linux-kernel
On Thu, 7 Jul 2005 23:10:33 +0200
Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> Do you use ACPI-based idling? If so, in which state is the CPU in (cat
> /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else
> you wouldn't need the table-based approach) or that the ACPI-based idling is
> broken on your notebook; as then the Linux idle handler only makes use of
> "hlt" (IIRC), that is ACPI C1, while throttling "forces" ACPI C2 (again
> IIRC).
For idling, I didn't mean 'real idling', but instead just 'doing nothing'
in ACPI C1 state, that's simply a CPU usage < 1%.
Sorry for being so lame =)
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 21:22 ` st3
@ 2005-07-07 21:29 ` Dominik Brodowski
0 siblings, 0 replies; 22+ messages in thread
From: Dominik Brodowski @ 2005-07-07 21:29 UTC (permalink / raw)
To: st3; +Cc: Dave Jones, cpufreq, linux-kernel
On Thu, Jul 07, 2005 at 11:22:38PM +0200, st3@riseup.net wrote:
> On Thu, 7 Jul 2005 23:10:33 +0200
> Dominik Brodowski <linux@dominikbrodowski.net> wrote:
>
> > Do you use ACPI-based idling? If so, in which state is the CPU in (cat
> > /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else
> > you wouldn't need the table-based approach) or that the ACPI-based idling is
> > broken on your notebook; as then the Linux idle handler only makes use of
> > "hlt" (IIRC), that is ACPI C1, while throttling "forces" ACPI C2 (again
> > IIRC).
>
> For idling, I didn't mean 'real idling', but instead just 'doing nothing'
> in ACPI C1 state, that's simply a CPU usage < 1%.
>
> Sorry for being so lame =)
That's exactly the "idling" I meant. So if it is only ACPI C1, then
throttling makes some sense. It makes more sense, though, to get ACPI C2, C3
and possibly C4 to work :)
Dominik
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 21:08 ` Dominik Brodowski
@ 2005-07-07 21:34 ` Joseph Pingenot
2005-07-07 21:51 ` Dominik Brodowski
0 siblings, 1 reply; 22+ messages in thread
From: Joseph Pingenot @ 2005-07-07 21:34 UTC (permalink / raw)
To: st3, Dave Jones, linux-kernel, cpufreq
>From Dominik Brodowski on Thursday, 07 July, 2005:
>On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote:
>> >Just a latest question: can be p4-clockmod used together with
>> >speedstep-centrino? If not, would it make any sense to patch
>> >speedstep-centrino to use this feature too?
>> I'm a little confused. How is this different from the ACPI CPU throttling
>> states (/proc/acpi/processor/CPUn/limit to set, throttling to see all
>> T-states available)?
>T-states _tend_ to be utilized using chipset logic, while p4-clockmod is
>done in-CPU.
>> On my 1.5-year-old Pentium-M, frequency scaling and T-states are different
>> beasties, and act entirely differently. I'm currently in the process of
>> rewriting my governor's brain to deal with the two more intelligently.
>In your case, I would care about throttling. In very most cases it actually
>increases energy consumption, as the state being entered is technically the
>same to ACPI C2 (IIRC), so it is only "forced" idling and only useful if
>"forced" idling is needed to not need active cooling.
Why would this cause more energy consumption?
-Joseph
--
trelane@digitasaru.net--------------------------------------------------
Graduate student in physics, Free Software developer.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
2005-07-07 21:34 ` Joseph Pingenot
@ 2005-07-07 21:51 ` Dominik Brodowski
0 siblings, 0 replies; 22+ messages in thread
From: Dominik Brodowski @ 2005-07-07 21:51 UTC (permalink / raw)
To: st3, Dave Jones, linux-kernel, cpufreq
On Thu, Jul 07, 2005 at 04:34:14PM -0500, Joseph Pingenot wrote:
> >From Dominik Brodowski on Thursday, 07 July, 2005:
> >On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote:
> >> >Just a latest question: can be p4-clockmod used together with
> >> >speedstep-centrino? If not, would it make any sense to patch
> >> >speedstep-centrino to use this feature too?
> >> I'm a little confused. How is this different from the ACPI CPU throttling
> >> states (/proc/acpi/processor/CPUn/limit to set, throttling to see all
> >> T-states available)?
> >T-states _tend_ to be utilized using chipset logic, while p4-clockmod is
> >done in-CPU.
> >> On my 1.5-year-old Pentium-M, frequency scaling and T-states are different
> >> beasties, and act entirely differently. I'm currently in the process of
> >> rewriting my governor's brain to deal with the two more intelligently.
> >In your case, I would care about throttling. In very most cases it actually
> >increases energy consumption, as the state being entered is technically the
> >same to ACPI C2 (IIRC), so it is only "forced" idling and only useful if
> >"forced" idling is needed to not need active cooling.
>
> Why would this cause more energy consumption?
Let's say a specific computing task needs 1s to run at 100% CPU load. The
CPU consumes 22 W at normal operation, and 7.3 W when in ACPI C2 state which
is technically equivalent to throttling. [note: these are _real_ values from
a real datasheet for a real CPU you see in common usage]
If you're at 0% CPU throttling rate, you need 22 Ws for this computing task,
if you're at 25% 24 Ws,
at 50% 29 Ws,
and at 75% that is 44 Ws for this computing task.
So for any sepcific computing task the energy consumption increases largely.
But what if the system idle otherwise?
If the CPU is put into an idle state the other time (e.g. there is no
other computing task for the CPU to do in a four-second span), it depends on
the idle state being used: if it is C2, these four seconds mean 44Ws of
energy being used; if it is C3, the CPU only needs 5.1Ws, so at 0% CPU
throttling you get 37 Ws; if it is C4, the CPU only needs 0.55Ws, so you
only get 24 Ws which is much less than the 44Ws you have at 75% throttling.
Please note that the weak spot in this calculation is the idle state the
CPU is forced to when doing idling. My investigations lead to the assumption
that it is the "Stop Grant" state on CPUs manufactored by Intel, which is
most often described by the ACPI C2 state ("Stop-Grant state"), while C3 is
"Deep Sleep State" or "Sleep State", and C4 is "Deeper Sleep State".
Dominik
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-06 19:58 ` Bill Davidsen
2005-07-06 21:11 ` Dave Jones
@ 2005-07-07 21:59 ` st3
2005-07-08 5:10 ` Dominik Brodowski
2005-07-08 10:59 ` Nikolay Pelov
1 sibling, 2 replies; 22+ messages in thread
From: st3 @ 2005-07-07 21:59 UTC (permalink / raw)
To: Bill Davidsen, linux-kernel; +Cc: cpufreq
On Wed, 06 Jul 2005 15:58:53 -0400
Bill Davidsen <davidsen@tmr.com> wrote:
> st3@riseup.net wrote:
[snip]
> > Moreover, I checked on Pentium M 725 and Pentium M 715 that the lowest
> > frequency at which the CPU can be set safely is not the 600MHz given in
> > datasheets, but 400MHz instead, with VID#A, VID#B, VID#C and VID#D (see
> > datasheet for more details) set to 0.908V.
> >
> > I can provide a patch, let me know.
>
> Slower is better
[snip]
Here's a quick trick for getting CPU to lower frequencies than the ones
read from ACPI tables, while still keeping them available.
Just add these lines in centrino_cpu_init_acpi(), in speedstep-centrino.c,
just after (and outside) the first 'for' cycle like this:
for (i=0; i<p.state_count; i++) { ...
centrino_model[cpu]->op_points[p.state_count - 1].index = 0x040D;
centrino_model[cpu]->op_points[p.state_count - 1].frequency = 400000;
p.states[p.state_count - 1].core_frequency = 400;
This will enable 400MHz at 908mV, which I found to be useful on Dothan
CPUs. If you want to get values for other frequencies/voltages, just use
something like:
#include <stdio.h>
int main() {
unsigned int index, frequency, voltage
index = (((frequency)/100) << 8) | ((voltage - 700) / 16);
printf ("%u\n", index);
}
frequency is expressed in MHz, voltage in mV, index is the value for
centrino_model[cpu]->op_points[y].index <- remember to change this y if you
want to add multiple frequencies besides the ACPI ones; for example, if you
want 500MHz at 940mV, you could add:
centrino_model[cpu]->op_points[p.state_count - 2].index = 0x1295;
centrino_model[cpu]->op_points[p.state_count - 2].index = 500000;
p.states[p.state_count - 2].core_frequency = 500;
Sorry if I have been off-topic.
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-07 21:59 ` st3
@ 2005-07-08 5:10 ` Dominik Brodowski
2005-07-08 8:58 ` st3
2005-07-08 10:59 ` Nikolay Pelov
1 sibling, 1 reply; 22+ messages in thread
From: Dominik Brodowski @ 2005-07-08 5:10 UTC (permalink / raw)
To: st3; +Cc: Bill Davidsen, linux-kernel, cpufreq
On Thu, Jul 07, 2005 at 11:59:28PM +0200, st3@riseup.net wrote:
> read from ACPI tables, while still keeping them available.
You're only keeping some of them available, as you overwrite one such
setting. Alternatively you can increase p.state_count by one early enough.
> index = (((frequency)/100) << 8) | ((voltage - 700) / 16);
> printf ("%u\n", index);
printf ("0x%x\n", index);
is better
> want 500MHz at 940mV, you could add:
>
> centrino_model[cpu]->op_points[p.state_count - 2].index = 0x1295;
> centrino_model[cpu]->op_points[p.state_count - 2].index = 500000;
.frequency
> p.states[p.state_count - 2].core_frequency = 500;
Dominik
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-08 5:10 ` Dominik Brodowski
@ 2005-07-08 8:58 ` st3
0 siblings, 0 replies; 22+ messages in thread
From: st3 @ 2005-07-08 8:58 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Bill Davidsen, linux-kernel, cpufreq
On Fri, 8 Jul 2005 07:10:50 +0200
Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> On Thu, Jul 07, 2005 at 11:59:28PM +0200, st3@riseup.net wrote:
> > read from ACPI tables, while still keeping them available.
>
> You're only keeping some of them available, as you overwrite one such
> setting. Alternatively you can increase p.state_count by one early enough.
Yes, but I was just overwriting the latest ones, that are never used =).
Anyway, your solution is theoretically better.
--
ciao
st3
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: speedstep-centrino on dothan
2005-07-07 21:59 ` st3
2005-07-08 5:10 ` Dominik Brodowski
@ 2005-07-08 10:59 ` Nikolay Pelov
1 sibling, 0 replies; 22+ messages in thread
From: Nikolay Pelov @ 2005-07-08 10:59 UTC (permalink / raw)
To: st3; +Cc: Bill Davidsen, linux-kernel, cpufreq
On Thu, 7 Jul 2005 st3@riseup.net wrote:
>
> int main() {
> unsigned int index, frequency, voltage
>
> index = (((frequency)/100) << 8) | ((voltage - 700) / 16);
> printf ("%u\n", index);
> }
>
> frequency is expressed in MHz, voltage in mV, index is the value for
> centrino_model[cpu]->op_points[y].index
Few days ago I discussed on the cpufreq mailing list that the above formula
is not the correct way to compute the index. Instead of frequency, one
should use a multiplier, i.e.:
index = (multiplier << 8) | ((voltage - 700) / 16);
and the multiplier is computed as multiplier = frequency/fsb_speed.
On older systems fsb_speed = 100 MHz and that's why the original formula
was working. But for the Sonoma (Centrino 2) Pentium M processors
fsb_speed = 133 MHz.
To give an example, take a CPU speed of 800MHz and a front side bus of
133MHz. Using the original formula we will use the value
frequency/100 = 800/100 = 8
which is wrong. The correct value is:
multiplier = frequency/fsb_speed = 800/133 = 6.
Nikolay
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2005-07-08 11:00 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-06 9:22 speedstep-centrino on dothan st3
2005-07-06 14:06 ` Dominik Brodowski
2005-07-06 19:45 ` st3
2005-07-06 16:30 ` Pedro Ramalhais
2005-07-06 19:58 ` Bill Davidsen
2005-07-06 21:11 ` Dave Jones
2005-07-06 21:55 ` st3
2005-07-07 20:00 ` enhanced intel speedstep feature was " st3
2005-07-07 20:06 ` Dave Jones
2005-07-07 20:22 ` st3
2005-07-07 20:40 ` Dave Jones
2005-07-07 20:51 ` Joseph Pingenot
2005-07-07 21:08 ` Dominik Brodowski
2005-07-07 21:34 ` Joseph Pingenot
2005-07-07 21:51 ` Dominik Brodowski
2005-07-07 21:10 ` Dominik Brodowski
2005-07-07 21:22 ` st3
2005-07-07 21:29 ` Dominik Brodowski
2005-07-07 21:59 ` st3
2005-07-08 5:10 ` Dominik Brodowski
2005-07-08 8:58 ` st3
2005-07-08 10:59 ` Nikolay Pelov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox