SMP C-states on x86_64 Status

SMP C-states on x86_64 Status

[Mathew Brown]

Hi,
  I just saw Adrian's post on a patch to add SMP C-states on x86_64 to
  kernel 2.6.16.  Is there anywhere I can find the current status of
  C-states on SMP machines?  I have a 16-core machine running RHEL with
  kernel 2.6.9-34 and it shows only C0, nothing else.  I checked the
  DSDT and it compiled without error.  Any ideas?  Thanks for your help.
-- 
  Mathew Brown
  mathewbrown@fastmail.fm

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?

Re: SMP C-states on x86_64 Status

[Len Brown]

On Sunday 05 November 2006 06:37, Mathew Brown wrote:
> Hi,
>   I just saw Adrian's post on a patch to add SMP C-states on x86_64 to
>   kernel 2.6.16.  Is there anywhere I can find the current status of
>   C-states on SMP machines?  I have a 16-core machine running RHEL with
>   kernel 2.6.9-34 and it shows only C0, nothing else.  I checked the
>   DSDT and it compiled without error.  Any ideas?  Thanks for your help.

This support (bugzilla 5653) shipped starting in 2.6.18, and I sent it to Adrian
for 2.6.16.stable -- and it appears it will pop out in 2.6.16.31.

Re: your 16 core machine running 2.6.9...
What does /proc/acpi/processor/*/power say?
I would expect it to say C1 only.

I would not expect this box to grow deeper C-states upon the support above.
The only SMP boxes with C-states deeper than C1 that I'm aware of today
are laptops.

cheers,
-Len

Re: SMP C-states on x86_64 Status

[Mathew Brown]

Thanks a lot for your input Len.  For my 16 core machine, cat
/proc/acpi/processor/*/power gives the following:

active state:  C1
default state: C1
bus master activity:   00000000
states:
  *C1:      promotion[--] demotion[--] latency[000] usage[0000000000]
    C2:      <not supported>
    C3:      <not supported>

So I gather that this means that even with CPU frequency scaling, I'm
really not doing anything since the voltage and power going to the CPU
are going to be constant until I upgrade to 2.6.18.  Am I correct?

Len Brown wrote:
> On Sunday 05 November 2006 06:37, Mathew Brown wrote:
>> Hi,
>>   I just saw Adrian's post on a patch to add SMP C-states on x86_64 to
>>   kernel 2.6.16.  Is there anywhere I can find the current status of
>>   C-states on SMP machines?  I have a 16-core machine running RHEL with
>>   kernel 2.6.9-34 and it shows only C0, nothing else.  I checked the
>>   DSDT and it compiled without error.  Any ideas?  Thanks for your help.
>
> This support (bugzilla 5653) shipped starting in 2.6.18, and I sent it to Adrian
> for 2.6.16.stable -- and it appears it will pop out in 2.6.16.31.
>
> Re: your 16 core machine running 2.6.9...
> What does /proc/acpi/processor/*/power say?
> I would expect it to say C1 only.
>
> I would not expect this box to grow deeper C-states upon the support above.
> The only SMP boxes with C-states deeper than C1 that I'm aware of today
> are laptops.
>
> cheers,
> -Len
>
>
>
-- 
  Mathew Brown
  mathewbrown@fastmail.fm

-- 
http://www.fastmail.fm - The way an email service should be

Re: SMP C-states on x86_64 Status

[Len Brown]

On Tuesday 07 November 2006 07:51, Mathew Brown wrote:
> .... For my 16 core machine, cat
> /proc/acpi/processor/*/power gives the following:
> 
> active state:  C1
> default state: C1
> bus master activity:   00000000
> states:
>   *C1:      promotion[--] demotion[--] latency[000] usage[0000000000]
>     C2:      <not supported>
>     C3:      <not supported>
> 
> So I gather that this means that even with CPU frequency scaling, I'm
> really not doing anything since the voltage and power going to the CPU
> are going to be constant until I upgrade to 2.6.18.  Am I correct?

C-states and P-states are somewhat independent.
You are not going to grow new C-states with a software upgrade.
If the processor at hand supports "Enhanced" C-states, then
it is going to reduce voltage automatically when you enter C1.

If your processor supports P-states, but not enhanced C-states,
then how much power you save in C1 will depend on what
P-state you were in when you entered C1.  This is because
even though you're running at 0MHz in C1, the lower voltage
will result in less power lost to leakage.

Running Linux's "ondemand" governor is pretty good at
getting you into a power saving P-state promptly, so if
you run that, then you're doing about as good as you can.
(you can compare it to "powersave" governor if you want
 to see what the lower power possible is)

You can see if you have P-states by poking about in
/sys/devices/system/cpu/cpu*/cpufreq/

modprobe cpufreq_states
will create a stats directory under there that will tell you
what P-states you are using.

cheers,
-Len