Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
On 12/6/19 2:44 PM, Naveen N. Rao wrote: > Naveen N. Rao wrote: >> Hi Nathan, >> >> Nathan Lynch wrote: >>> Hi Kamalesh, >>> >>> Kamalesh Babulal writes: On 12/5/19 3:54 AM, Nathan Lynch wrote: > "Gautham R. Shenoy" 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
Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
Naveen N. Rao wrote: Hi Nathan, Nathan Lynch wrote: Hi Kamalesh, Kamalesh Babulal writes: On 12/5/19 3:54 AM, Nathan Lynch wrote: "Gautham R. Shenoy" 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. - Naveen
Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
Hi Nathan, Nathan Lynch wrote: Hi Kamalesh, Kamalesh Babulal writes: On 12/5/19 3:54 AM, Nathan Lynch wrote: "Gautham R. Shenoy" 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. - Naveen
Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
Hi Kamalesh, Kamalesh Babulal writes: > On 12/5/19 3:54 AM, Nathan Lynch wrote: >> "Gautham R. Shenoy" 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.
Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
On 12/5/19 3:54 AM, Nathan Lynch wrote: > "Gautham R. Shenoy" writes: >> From: "Gautham R. Shenoy" >> >> On PSeries LPARs, the data centers planners desire a more accurate >> view of system utilization per resource such as CPU to plan the system >> capacity requirements better. Such accuracy can be obtained by reading >> PURR/SPURR registers for CPU resource utilization. >> >> 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. -- Kamalesh
Re: [PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
"Gautham R. Shenoy" writes: > From: "Gautham R. Shenoy" > > On PSeries LPARs, the data centers planners desire a more accurate > view of system utilization per resource such as CPU to plan the system > capacity requirements better. Such accuracy can be obtained by reading > PURR/SPURR registers for CPU resource utilization. > > 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.
[PATCH 0/3] pseries: Track and expose idle PURR and SPURR ticks
From: "Gautham R. Shenoy" On PSeries LPARs, the data centers planners desire a more accurate view of system utilization per resource such as CPU to plan the system capacity requirements better. Such accuracy can be obtained by reading PURR/SPURR registers for CPU resource utilization. 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. These patches are required for enhancement to the lparstat utility that compute the CPU utilization based on PURR and SPURR which can be found here : https://groups.google.com/forum/#!topic/powerpc-utils-devel/fYRo69xO9r4 Gautham R. Shenoy (3): powerpc/pseries: Account for SPURR ticks on idle CPUs powerpc/sysfs: Show idle_purr and idle_spurr for every CPU Documentation: Document sysfs interfaces purr, spurr, idle_purr, idle_spurr Documentation/ABI/testing/sysfs-devices-system-cpu | 39 ++ arch/powerpc/kernel/idle.c | 2 ++ arch/powerpc/kernel/sysfs.c| 32 ++ drivers/cpuidle/cpuidle-pseries.c | 28 ++-- 4 files changed, 90 insertions(+), 11 deletions(-) -- 1.9.4
