On 12/6/19 2:44 PM, Naveen N. Rao wrote: > Naveen N. Rao wrote: >> Hi Nathan, >> >> Nathan Lynch wrote: >>> Hi Kamalesh, >>> >>> Kamalesh Babulal <kamal...@linux.vnet.ibm.com> writes: >>>> On 12/5/19 3:54 AM, Nathan Lynch wrote: >>>>> "Gautham R. Shenoy" <e...@linux.vnet.ibm.com> writes: >>>>>> >>>>>> 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. > > Re-reading this today morning, I realize that this isn't entirely accurate. > SPURR alone is sufficient to understand core resource utilization. > > Kamalesh is using PURR to display non-normalized utilization values (under > 'actual' column), as reported by lparstat on AIX. I am not entirely sure if > it is ok to derive these based on the SPURR busy/idle ratio.
Both idle_purr and idle_spurr complement each other and we need to expose both of them. It will improve the accounting accuracy of tools currently consuming system-wide PURR and/or SPURR numbers to report system usage. Deriving one from another, from my experience makes it hard for tools or any custom scripts to give an accurate system view. One tool I am aware of is lparstat, which uses PURR based metrics. -- Kamalesh
