Package C-state Residency Counters

[CyrIng]

Hello,

A zero value is returned when reading the msr registers at

• 3F8H (MSR_PKG_C3_RESIDENCY)
• 3F9H (MSR_PKG_C6_RESIDENCY)
• 3FAH (MSR_PKG_C7_RESIDENCY) 

( this is done with a Bloomfield processor, architecture Nehalem, in a Linux driver with Ring0 access level, using the Core BSP )

Although they are documented "Value since last reset" in Vol.3C, table 35-13, I tried also to write some "Package C-State Limit" bits [2:0] in msr E2H (MSR_PKG_CST_CONFIG_ CONTROL). No success.

Are those counters really exist on Nehalem ?

What can be the process to activate them ? 

Regards

CyrIng

[CyrIng]

So far, best answer is provided in biosbits

Via the rdmsr command, we see that the BIOS has limited package C-states by setting MSR 0xE2 bits [2:0] to 1. However, this BIOS did have an option to disable locking of that register, and using that option turned off the lock bit (bit 15). So, we can fix it via the wrmsr command, and now we get package C-states

[CyrIng]

Surprisingly package state counters have values with Haswell but not with Nehalem ! My last version of the software allows to show percentage of each counter divided by TSC Just press the % key in CoreFreq @ http://github.com/cyring/CoreFreq

[McCalpinJohn]

Sometimes the implementations actually improve over time!   Sometimes they don't... :-(

It is very difficult to come up with architectural features that will stand the test of time.   With the increase in attention to power consumption, package C-states have become more important over time.   Since the Package C-state residency counters are clearly labeled as referring to processor-specific C-state names (rather than ACPI C-state names), this feature has the good combination of being both important and flexible.

Other features have been more problematic.  RAPL is an example -- the original definitions refer to "domains" that are not necessarily practical to track as processor designs become more complex.   The original definitions also failed to define an interface that software could use to determine which RAPL features exist on a given processor, so a code has to either include tables of which features are supported by each DisplayFamily_DisplayModel combination, or include code that can deal with MSR reads that fail.   The logic needs to be considered carefully, since at least one processor (Haswell EP) allows reads from at least one of the PP0 domain MSRs, but does not actually support the domain.

I am glad you found some answers at biosbits.org -- the last time I looked there (not recently) I was not able to find any useful information.