Re: Leaving the Desktop Market

On 2014-05-17 08:07, John Baldwin wrote:
> On 5/12/14, 1:35 PM, Allan Jude wrote:
>> I have this system:
>>
>> hw.model: Intel(R) Xeon(R) CPU E3-1220 v3 _at_ 3.10GHz
>> hw.ncpu: 4
>>
>> http://ark.intel.com/products/75052
>>
>> dev.cpu.0.%desc: ACPI CPU
>> dev.cpu.0.%driver: cpu
>> dev.cpu.0.%location: handle=\_PR_.CPU0
>> dev.cpu.0.%pnpinfo: _HID=none _UID=0
>> dev.cpu.0.%parent: acpi0
>> dev.cpu.0.freq: 3100
>> dev.cpu.0.freq_levels: 3101/80000 3100/80000 2900/72713 2800/69558
>> 2600/62669 2400/56794 2300/53935 2100/47673 1900/42370 1800/39795
>> 1600/34136 1500/31729 1300/26432 1137/23128 1100/21994 1000/19851
>> 875/17369 800/15113 700/13223 600/11334 500/9445 400/7556 300/5667
>> 200/3778 100/1889
>> dev.cpu.0.cx_supported: C1/1/1 C2/2/148
>> dev.cpu.0.cx_lowest: C8
>> dev.cpu.0.cx_usage: 9.01% 90.98% last 807us
>> dev.cpu.1.%desc: ACPI CPU
>> dev.cpu.1.%driver: cpu
>> dev.cpu.1.%location: handle=\_PR_.CPU1
>> dev.cpu.1.%pnpinfo: _HID=none _UID=0
>> dev.cpu.1.%parent: acpi0
>> dev.cpu.1.cx_supported: C1/1/1 C2/2/148
>> dev.cpu.1.cx_lowest: C8
>> dev.cpu.1.cx_usage: 11.70% 88.29% last 21303us
>> dev.cpu.2.%desc: ACPI CPU
>> dev.cpu.2.%driver: cpu
>> dev.cpu.2.%location: handle=\_PR_.CPU2
>> dev.cpu.2.%pnpinfo: _HID=none _UID=0
>> dev.cpu.2.%parent: acpi0
>> dev.cpu.2.cx_supported: C1/1/1 C2/2/148
>> dev.cpu.2.cx_lowest: C8
>> dev.cpu.2.cx_usage: 15.17% 84.82% last 22987us
>> dev.cpu.3.%desc: ACPI CPU
>> dev.cpu.3.%driver: cpu
>> dev.cpu.3.%location: handle=\_PR_.CPU3
>> dev.cpu.3.%pnpinfo: _HID=none _UID=0
>> dev.cpu.3.%parent: acpi0
>> dev.cpu.3.cx_supported: C1/1/1 C2/2/148
>> dev.cpu.3.cx_lowest: C8
>> dev.cpu.3.cx_usage: 11.74% 88.25% last 6073us
>>
>>
>> According to the Intel specs (Page 11), this processor supports C1, C1E,
>> C3, C6 and C7
>>
>> The above sysctl dump shows only C1 and C2. I wonder if the C2 is
>> actually C3
> Yes, ACPI C states != CPU C states.  Often C6/C7 map to C3.  You might
> have a BIOS option to control C6/C7.  I've seen several BIOSes that
> default to only exporting Intel C3 as C2, but do not advertise Intel
> C6/C7 as C3 until you enable that in the BIOS.
>
>> http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e3-1200v3-vol-1-datasheet.pdf
>>
>> How is our support for the newer Cx States introduced in Haswell, which
>> can apparently go as high as C10
> For idling, any Intel Cx state should work as long as the BIOS is
> configured to export it as an ACPI Cx state.
>
Yes, using the intel-pcm tool from ports that Adrian suggested allowed
me to check and confirm that when ACPI C3 is being used, the CPU is
going to C7 on cores and C6 for the entire package, as well as giving
detailed statistics


The only thing that I noticed is that the cx_usage stats do not get
updated under 100% cpu load (when the CPU never leaves C0)

This can be confusing when it suggests that the core is spending 50% of
its time in C3 when it is in fact not, but I am not familiar with this
part of the system to know if that is something that i sour fault or
ACPIs, and if it is fixable. Just reporting my observations