Hi Nathan,

Nathan Lynch wrote:

Hi Kamalesh,

Kamalesh Babulal [off-list ref] writes:

quoted

On 12/5/19 3:54 AM, Nathan Lynch wrote:

quoted

"Gautham R. Shenoy" [off-list ref] writes:

quoted

Tools such as lparstat which are used to compute the utilization need
to know [S]PURR ticks when the cpu was busy or idle. The [S]PURR
counters are already exposed through sysfs.  We already account for
PURR ticks when we go to idle so that we can update the VPA area. This
patchset extends support to account for SPURR ticks when idle, and
expose both via per-cpu sysfs files.

Does anything really want to use PURR instead of SPURR? Seems like we
should expose only SPURR idle values if possible.

lparstat is one of the consumers of PURR idle metric
(https://groups.google.com/forum/#!topic/powerpc-utils-devel/fYRo69xO9r4). 
Agree, on the argument that system utilization metrics based on SPURR
accounting is accurate in comparison to PURR, which isn't proportional to
CPU frequency.  PURR has been traditionally used to understand the system
utilization, whereas SPURR is used for understanding how much capacity is
left/exceeding in the system based on the current power saving mode.

I'll phrase my question differently: does SPURR complement or supercede
PURR? You seem to be saying they serve different purposes. If PURR is
actually useful rather then vestigial then I have no objection to
exposing idle_purr.

SPURR complements PURR, so we need both. SPURR/PURR ratio helps provide 
an indication of the available headroom in terms of core resources, at 
maximum frequency.


- Naveen