From: Gautham R. Shenoy <hidden> Date: 2020-03-27 11:33:24
From: "Gautham R. Shenoy" <redacted>
Hi,
This is the fourth version of the patches to track and expose idle PURR
and SPURR ticks. These patches are required by tools such as lparstat
to compute system utilization for capacity planning purposes.
The previous versions can be found here:
v3: https://lkml.org/lkml/2020/3/11/331
v2: https://lkml.org/lkml/2020/2/21/21
v1: https://lore.kernel.org/patchwork/cover/1159341/
They key changes from v3 are:
- Fixed the build errors on !CONFIG_PPC64 and !CONFIG_PPC_PSERIES
configurations notified by the kbuild bot.
Motivation:
===========
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.
This patch series also introduces a patch (Patch 6/6) to send an IPI
in order to read and cache the values of purr, spurr, idle_purr and
idle_spurr of the target CPU when any one of them is read via
sysfs. These cached values will be presented if any of these sysfs are
read within the next 10ms. If these sysfs files are read after 10ms
from the earlier IPI, a fresh IPI is issued to read and cache the
values again. This minimizes the number of IPIs required to be sent
when these values are read back-to-back via the sysfs interface.
Without patch 6/6 (Without caching):
16 [XICS 2 Edge IPI] = 422 times
DBL [Doorbell interrupts] = 13 times
Total : 435 IPIs.
With patch 6/6 (With caching):
16 [XICS 2 Edge IPI] = 111 times
DBL [Doorbell interrupts] = 17 times
Total : 128 IPIs.
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
With the patches, when lparstat is run on a LPAR running CPU-Hogs,
=========================================================================
sudo ./src/lparstat -E 1 3
System Configuration
type=Dedicated mode=Capped smt=8 lcpu=2 mem=4834176 kB cpus=0 ent=2.00
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
------ ------ ------------- ------ ------
99.99 0.00 3.35GHz[111%] 110.99 0.00
100.00 0.00 3.35GHz[111%] 111.00 0.00
100.00 0.00 3.35GHz[111%] 111.00 0.00
With patches, when lparstat is run on and idle LPAR
=========================================================================
---Actual--- -Normalized-
%busy %idle Frequency %busy %idle
------ ------ ------------- ------ ------
0.20 99.81 2.17GHz[ 72%] 0.19 71.82
0.42 99.58 2.11GHz[ 70%] 0.31 69.69
0.41 99.59 2.11GHz[ 70%] 0.31 69.69
Gautham R. Shenoy (6):
powerpc: Move idle_loop_prolog()/epilog() functions to header file
powerpc/idle: Add accessor function to always read latest idle PURR
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
pseries/sysfs: Minimise IPI noise while reading [idle_][s]purr
Documentation/ABI/testing/sysfs-devices-system-cpu | 39 +++++
arch/powerpc/include/asm/idle.h | 93 ++++++++++++
arch/powerpc/kernel/sysfs.c | 167 ++++++++++++++++++++-
arch/powerpc/platforms/pseries/setup.c | 8 +-
drivers/cpuidle/cpuidle-pseries.c | 39 +----
5 files changed, 305 insertions(+), 41 deletions(-)
create mode 100644 arch/powerpc/include/asm/idle.h
--
1.9.4
From: Gautham R. Shenoy <hidden> Date: 2020-03-27 11:33:04
From: "Gautham R. Shenoy" <redacted>
On Pseries LPARs, to calculate utilization, we need to know the
[S]PURR ticks when the CPUs were busy or idle.
Via pseries_idle_prolog(), pseries_idle_epilog(), we track the idle
PURR ticks in the VPA variable "wait_state_cycles". This patch extends
the support to account for the idle SPURR ticks. It also provides an
accessor function to accurately reads idle SPURR ticks.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/include/asm/idle.h | 33 +++++++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/setup.c | 2 ++
2 files changed, 35 insertions(+)
From: Gautham R. Shenoy <hidden> Date: 2020-03-27 11:33:05
From: "Gautham R. Shenoy" <redacted>
Currently purr, spurr, idle_purr, idle_spurr are exposed for every CPU
via the sysfs interface
/sys/devices/system/cpu/cpuX/[idle_][s]purr. Each sysfs read currently
generates an IPI to obtain the desired value from the target CPU X.
Since these aforementioned sysfs are typically read one after another,
we end up generating 4 IPIs per CPU in a short duration.
In order to minimize the IPI noise, this patch caches the values of
all the four entities whenever one of them is read. If subsequently
any of these are read within the next 10ms, the cached value is
returned. With this, we will generate at most one IPI every 10ms for
every CPU.
Test-results: While reading the four sysfs files back-to-back for a
given CPU every second for 100 seconds.
Without the patch:
16 [XICS 2 Edge IPI] = 422 times
DBL [Doorbell interrupts] = 13 times
Total : 435 IPIs.
With the patch:
16 [XICS 2 Edge IPI] = 111 times
DBL [Doorbell interrupts] = 17 times
Total : 128 IPIs.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/kernel/sysfs.c | 117 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 97 insertions(+), 20 deletions(-)
@@ -580,3 +580,42 @@ Description: Secure Virtual Machine If 1, it means the system is using the Protected Execution Facility in POWER9 and newer processors. i.e., it is a Secure Virtual Machine.++What: /sys/devices/system/cpu/cpuX/purr+Date: Apr 2005+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: PURR ticks for this CPU since the system boot.++ The Processor Utilization Resources Register (PURR) is+ a 64-bit counter which provides an estimate of the+ resources used by the CPU thread. The contents of this+ register increases monotonically. This sysfs interface+ exposes the number of PURR ticks for cpuX.++What: /sys/devices/system/cpu/cpuX/spurr+Date: Dec 2006+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: SPURR ticks for this CPU since the system boot.++ The Scaled Processor Utilization Resources Register+ (SPURR) is a 64-bit counter that provides a frequency+ invariant estimate of the resources used by the CPU+ thread. The contents of this register increases+ monotonically. This sysfs interface exposes the number+ of SPURR ticks for cpuX.++What: /sys/devices/system/cpu/cpuX/idle_purr+Date: Mar 2020+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: PURR ticks for cpuX when it was idle.++ This sysfs interface exposes the number of PURR ticks+ for cpuX when it was idle.++What: /sys/devices/system/cpu/cpuX/idle_spurr+Date: Mar 2020+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: SPURR ticks for cpuX when it was idle.++ This sysfs interface exposes the number of SPURR ticks+ for cpuX when it was idle.
From: Gautham R. Shenoy <hidden> Date: 2020-03-27 11:33:10
From: "Gautham R. Shenoy" <redacted>
On Pseries LPARs, to calculate utilization, we need to know the
[S]PURR ticks when the CPUs were busy or idle.
The total PURR and SPURR ticks are already exposed via the per-cpu
sysfs files "purr" and "spurr". This patch adds support for exposing
the idle PURR and SPURR ticks via new per-cpu sysfs files named
"idle_purr" and "idle_spurr".
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/kernel/sysfs.c | 82 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 79 insertions(+), 3 deletions(-)
@@ -823,10 +892,13 @@ static int register_cpu_online(unsigned int cpu)if(!firmware_has_feature(FW_FEATURE_LPAR))add_write_permission_dev_attr(&dev_attr_purr);device_create_file(s,&dev_attr_purr);+create_idle_purr_file(s);}-if(cpu_has_feature(CPU_FTR_SPURR))+if(cpu_has_feature(CPU_FTR_SPURR)){device_create_file(s,&dev_attr_spurr);+create_idle_spurr_file(s);+}if(cpu_has_feature(CPU_FTR_DSCR))device_create_file(s,&dev_attr_dscr);
@@ -910,11 +982,15 @@ static int unregister_cpu_online(unsigned int cpu)device_remove_file(s,&dev_attr_mmcra);#endif /* CONFIG_PMU_SYSFS */-if(cpu_has_feature(CPU_FTR_PURR))+if(cpu_has_feature(CPU_FTR_PURR)){device_remove_file(s,&dev_attr_purr);+remove_idle_purr_file(s);+}-if(cpu_has_feature(CPU_FTR_SPURR))+if(cpu_has_feature(CPU_FTR_SPURR)){device_remove_file(s,&dev_attr_spurr);+remove_idle_spurr_file(s);+}if(cpu_has_feature(CPU_FTR_DSCR))device_remove_file(s,&dev_attr_dscr);
From: Gautham R. Shenoy <hidden> Date: 2020-03-27 11:33:19
From: "Gautham R. Shenoy" <redacted>
Currently prior to entering an idle state on a Linux Guest, the
pseries cpuidle driver implement an idle_loop_prolog() and
idle_loop_epilog() functions which ensure that idle_purr is correctly
computed, and the hypervisor is informed that the CPU cycles have been
donated.
These prolog and epilog functions are also required in the default
idle call, i.e pseries_lpar_idle(). Hence move these accessor
functions to a common header file and call them from
pseries_lpar_idle(). Since the existing header files such as
asm/processor.h have enough clutter, create a new header file
asm/idle.h. Finally rename idle_loop_prolog() and idle_loop_epilog()
to pseries_idle_prolog() and pseries_idle_epilog() as they are only
relavent for on pseries guests.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/include/asm/idle.h | 31 +++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/setup.c | 7 +++++--
drivers/cpuidle/cpuidle-pseries.c | 36 +++++++---------------------------
3 files changed, 43 insertions(+), 31 deletions(-)
create mode 100644 arch/powerpc/include/asm/idle.h
@@ -319,6 +320,8 @@ static int alloc_dispatch_log_kmem_cache(void)staticvoidpseries_lpar_idle(void){+unsignedlongin_purr;+/**Defaulthandlertogointolowthreadpriorityandpossibly*lowpowermodebycedingprocessortohypervisor
@@ -328,7 +331,7 @@ static void pseries_lpar_idle(void)return;/* Indicate to hypervisor that we are idle. */-get_lppaca()->idle=1;+pseries_idle_prolog(&in_purr);/**Yieldtheprocessortothehypervisor.Wereturnif
From: Gautham R. Shenoy <hidden> Date: 2020-03-27 11:33:28
From: "Gautham R. Shenoy" <redacted>
Currently when CPU goes idle, we take a snapshot of PURR via
pseries_idle_prolog() which is used at the CPU idle exit to compute
the idle PURR cycles via the function pseries_idle_epilog(). Thus,
the value of idle PURR cycle thus read before pseries_idle_prolog() and
after pseries_idle_epilog() is always correct.
However, if we were to read the idle PURR cycles from an interrupt
context between pseries_idle_prolog() and pseries_idle_epilog() (this will
be done in a future patch), then, the value of the idle PURR thus read
will not include the cycles spent in the most recent idle period.
This patch addresses the issue by providing accessor function to read
the idle PURR such such that it includes the cycles spent in the most
recent idle period, if we read it between pseries_idle_prolog() and
pseries_idle_epilog(). In order to achieve it, the patch saves the
snapshot of PURR in pseries_idle_prolog() in a per-cpu variable,
instead of on the stack, so that it can be accessed from an interrupt
context.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/include/asm/idle.h | 47 +++++++++++++++++++++++++++-------
arch/powerpc/platforms/pseries/setup.c | 7 +++--
drivers/cpuidle/cpuidle-pseries.c | 15 +++++------
3 files changed, 47 insertions(+), 22 deletions(-)
@@ -318,10 +318,9 @@ static int alloc_dispatch_log_kmem_cache(void)}machine_early_initcall(pseries,alloc_dispatch_log_kmem_cache);+DEFINE_PER_CPU(u64,idle_entry_purr_snap);staticvoidpseries_lpar_idle(void){-unsignedlongin_purr;-/**Defaulthandlertogointolowthreadpriorityandpossibly*lowpowermodebycedingprocessortohypervisor
@@ -331,7 +330,7 @@ static void pseries_lpar_idle(void)return;/* Indicate to hypervisor that we are idle. */-pseries_idle_prolog(&in_purr);+pseries_idle_prolog();/**Yieldtheprocessortothehypervisor.Wereturnif
From: Naveen N. Rao <hidden> Date: 2020-04-01 09:43:05
Hi Gautham,
Gautham R. Shenoy wrote:
quoted hunk
From: "Gautham R. Shenoy" <redacted>
Currently when CPU goes idle, we take a snapshot of PURR via
pseries_idle_prolog() which is used at the CPU idle exit to compute
the idle PURR cycles via the function pseries_idle_epilog(). Thus,
the value of idle PURR cycle thus read before pseries_idle_prolog() and
after pseries_idle_epilog() is always correct.
However, if we were to read the idle PURR cycles from an interrupt
context between pseries_idle_prolog() and pseries_idle_epilog() (this will
be done in a future patch), then, the value of the idle PURR thus read
will not include the cycles spent in the most recent idle period.
This patch addresses the issue by providing accessor function to read
the idle PURR such such that it includes the cycles spent in the most
recent idle period, if we read it between pseries_idle_prolog() and
pseries_idle_epilog(). In order to achieve it, the patch saves the
snapshot of PURR in pseries_idle_prolog() in a per-cpu variable,
instead of on the stack, so that it can be accessed from an interrupt
context.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/include/asm/idle.h | 47 +++++++++++++++++++++++++++-------
arch/powerpc/platforms/pseries/setup.c | 7 +++--
drivers/cpuidle/cpuidle-pseries.c | 15 +++++------
3 files changed, 47 insertions(+), 22 deletions(-)
@@ -580,3 +580,42 @@ Description: Secure Virtual Machine If 1, it means the system is using the Protected Execution Facility in POWER9 and newer processors. i.e., it is a Secure Virtual Machine.++What: /sys/devices/system/cpu/cpuX/purr+Date: Apr 2005+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: PURR ticks for this CPU since the system boot.++ The Processor Utilization Resources Register (PURR) is+ a 64-bit counter which provides an estimate of the+ resources used by the CPU thread. The contents of this+ register increases monotonically. This sysfs interface+ exposes the number of PURR ticks for cpuX.++What: /sys/devices/system/cpu/cpuX/spurr+Date: Dec 2006+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: SPURR ticks for this CPU since the system boot.++ The Scaled Processor Utilization Resources Register+ (SPURR) is a 64-bit counter that provides a frequency+ invariant estimate of the resources used by the CPU+ thread. The contents of this register increases+ monotonically. This sysfs interface exposes the number+ of SPURR ticks for cpuX.++What: /sys/devices/system/cpu/cpuX/idle_purr+Date: Mar 2020+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: PURR ticks for cpuX when it was idle.++ This sysfs interface exposes the number of PURR ticks+ for cpuX when it was idle.++What: /sys/devices/system/cpu/cpuX/idle_spurr+Date: Mar 2020+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>+Description: SPURR ticks for cpuX when it was idle.++ This sysfs interface exposes the number of SPURR ticks+ for cpuX when it was idle.
Apart from the minor comment on patches 2 and 3, from the sysfs
interface standpoint, for patches 1 to 5:
Acked-by: Naveen N. Rao <redacted>
- Naveen
From: Naveen N. Rao <hidden> Date: 2020-04-01 09:58:59
Gautham R. Shenoy wrote:
quoted hunk
From: "Gautham R. Shenoy" <redacted>
Currently purr, spurr, idle_purr, idle_spurr are exposed for every CPU
via the sysfs interface
/sys/devices/system/cpu/cpuX/[idle_][s]purr. Each sysfs read currently
generates an IPI to obtain the desired value from the target CPU X.
Since these aforementioned sysfs are typically read one after another,
we end up generating 4 IPIs per CPU in a short duration.
In order to minimize the IPI noise, this patch caches the values of
all the four entities whenever one of them is read. If subsequently
any of these are read within the next 10ms, the cached value is
returned. With this, we will generate at most one IPI every 10ms for
every CPU.
Test-results: While reading the four sysfs files back-to-back for a
given CPU every second for 100 seconds.
Without the patch:
16 [XICS 2 Edge IPI] = 422 times
DBL [Doorbell interrupts] = 13 times
Total : 435 IPIs.
With the patch:
16 [XICS 2 Edge IPI] = 111 times
DBL [Doorbell interrupts] = 17 times
Total : 128 IPIs.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/kernel/sysfs.c | 117 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 97 insertions(+), 20 deletions(-)
This alters the behavior of the current sysfs purr file. I am not sure
if it is reasonable to return the same PURR value across a 10ms window.
I wonder if we should introduce a sysctl interface to control
thresholding. It can default to 0, which disables thresholding so that
the existing behavior continues. Applications (lparstat) can optionally
set it to suit their use.
- Naveen
}
#endif /* CONFIG_PPC_SVM */
+#ifdef CONFIG_PPC64
+/*
+ * The duration (in ms) from the last IPI to the target CPU until
+ * which a cached value of purr, spurr, idle_purr, idle_spurr can be
+ * reported to the user on a corresponding sysfs file read. Beyond
+ * this duration, fresh values need to be obtained by sending IPIs to
+ * the target CPU when the sysfs files are read.
+ */
+static unsigned long util_stats_staleness_tolerance_ms = 10;
This is a nice optimization for our use in lparstat, though I have a concern
below.
This alters the behavior of the current sysfs purr file. I am not sure if it
is reasonable to return the same PURR value across a 10ms window.
It does reduce it to 10ms window. I am not sure if anyone samples PURR
etc faster than that rate.
I measured how much time it takes to read the purr, spurr, idle_purr,
idle_spurr files back-to-back. It takes not more than 150us. From
lparstat will these values be read back-to-back ? If so, we can reduce
the staleness_tolerance to something like 500us and still avoid extra
IPIs. If not, what is the maximum delay between the first sysfs file
read and the last sysfs file read ?
I wonder if we should introduce a sysctl interface to control thresholding.
It can default to 0, which disables thresholding so that the existing
behavior continues. Applications (lparstat) can optionally set it to suit
their use.
We would be introducing 3 new sysfs interfaces that way instead of
two.
/sys/devices/system/cpu/purr_spurr_staleness
/sys/devices/system/cpu/cpuX/idle_purr
/sys/devices/system/cpu/cpuX/idle_spurr
I don't have a problem with this. Nathan, Michael, thoughts on this?
The alternative is to have a procfs interface, something like
/proc/powerpc/resource_util_stats
which gives a listing similar to /proc/stat, i.e
CPUX <purr> <idle_purr> <spurr> <idle_spurr>
Even in this case, the values can be obtained in one-shot with a
single IPI and be printed in the row corresponding to the CPU.
This alters the behavior of the current sysfs purr file. I am not sure if it
is reasonable to return the same PURR value across a 10ms window.
It does reduce it to 10ms window. I am not sure if anyone samples PURR
etc faster than that rate.
I measured how much time it takes to read the purr, spurr, idle_purr,
idle_spurr files back-to-back. It takes not more than 150us. From
lparstat will these values be read back-to-back ? If so, we can reduce
the staleness_tolerance to something like 500us and still avoid extra
IPIs. If not, what is the maximum delay between the first sysfs file
read and the last sysfs file read ?
Oh, for lparstat usage, this is perfectly fine.
I meant that there could be other users of [s]purr who might care. I
don't know of one, but since this is an existing sysfs interface, I
wanted to point out that the behavior might change.
quoted
I wonder if we should introduce a sysctl interface to control thresholding.
It can default to 0, which disables thresholding so that the existing
behavior continues. Applications (lparstat) can optionally set it to suit
their use.
We would be introducing 3 new sysfs interfaces that way instead of
two.
/sys/devices/system/cpu/purr_spurr_staleness
/sys/devices/system/cpu/cpuX/idle_purr
/sys/devices/system/cpu/cpuX/idle_spurr
I don't have a problem with this. Nathan, Michael, thoughts on this?
The alternative is to have a procfs interface, something like
/proc/powerpc/resource_util_stats
which gives a listing similar to /proc/stat, i.e
CPUX <purr> <idle_purr> <spurr> <idle_spurr>
Even in this case, the values can be obtained in one-shot with a
single IPI and be printed in the row corresponding to the CPU.
Right -- and that would be optimal requiring a single system call, at
the cost of using a legacy interface.
The other option would be to drop this patch and to just go with patches
1-5 introducing the new sysfs interfaces for idle_[s]purr. It isn't
entirely clear how often this would be used, or its actual impact. We
can perhaps consider this optimization if and when this causes
problems...
Thanks,
Naveen
From: Gautham R Shenoy <hidden> Date: 2020-04-03 06:22:36
On Wed, Apr 01, 2020 at 03:12:53PM +0530, Naveen N. Rao wrote:
Hi Gautham,
Gautham R. Shenoy wrote:
quoted
From: "Gautham R. Shenoy" <redacted>
Currently when CPU goes idle, we take a snapshot of PURR via
pseries_idle_prolog() which is used at the CPU idle exit to compute
the idle PURR cycles via the function pseries_idle_epilog(). Thus,
the value of idle PURR cycle thus read before pseries_idle_prolog() and
after pseries_idle_epilog() is always correct.
However, if we were to read the idle PURR cycles from an interrupt
context between pseries_idle_prolog() and pseries_idle_epilog() (this will
be done in a future patch), then, the value of the idle PURR thus read
will not include the cycles spent in the most recent idle period.
This patch addresses the issue by providing accessor function to read
the idle PURR such such that it includes the cycles spent in the most
recent idle period, if we read it between pseries_idle_prolog() and
pseries_idle_epilog(). In order to achieve it, the patch saves the
snapshot of PURR in pseries_idle_prolog() in a per-cpu variable,
instead of on the stack, so that it can be accessed from an interrupt
context.
Signed-off-by: Gautham R. Shenoy <redacted>
---
arch/powerpc/include/asm/idle.h | 47 +++++++++++++++++++++++++++-------
arch/powerpc/platforms/pseries/setup.c | 7 +++--
drivers/cpuidle/cpuidle-pseries.c | 15 +++++------
3 files changed, 47 insertions(+), 22 deletions(-)
#include <asm/paca.h>
#ifdef CONFIG_PPC_PSERIES
-static inline void pseries_idle_prolog(unsigned long *in_purr)
+DECLARE_PER_CPU(u64, idle_entry_purr_snap);
+
+static inline void snapshot_purr_idle_entry(void)
+{
+ *this_cpu_ptr(&idle_entry_purr_snap) = mfspr(SPRN_PURR);
+}
+
+static inline void update_idle_purr_accounting(void)
+{
+ u64 wait_cycles;
+ u64 in_purr = *this_cpu_ptr(&idle_entry_purr_snap);
+
+ wait_cycles = be64_to_cpu(get_lppaca()->wait_state_cycles);
+ wait_cycles += mfspr(SPRN_PURR) - in_purr;
+ get_lppaca()->wait_state_cycles = cpu_to_be64(wait_cycles);
+}
+
+static inline void pseries_idle_prolog(void)
{
ppc64_runlatch_off();
- *in_purr = mfspr(SPRN_PURR);
+ snapshot_purr_idle_entry();
/*
* Indicate to the HV that we are idle. Now would be
* a good time to find other work to dispatch.
@@ -16,16 +33,28 @@ static inline void pseries_idle_prolog(unsigned long *in_purr)
get_lppaca()->idle = 1;
}
-static inline void pseries_idle_epilog(unsigned long in_purr)
+static inline void pseries_idle_epilog(void)
{
- u64 wait_cycles;
-
- wait_cycles = be64_to_cpu(get_lppaca()->wait_state_cycles);
- wait_cycles += mfspr(SPRN_PURR) - in_purr;
- get_lppaca()->wait_state_cycles = cpu_to_be64(wait_cycles);
+ update_idle_purr_accounting();
get_lppaca()->idle = 0;
-
ppc64_runlatch_on();
}
+
+static inline u64 read_this_idle_purr(void)
+{
+ /*
+ * If we are reading from an idle context, update the
+ * idle-purr cycles corresponding to the last idle period.
+ * Since the idle context is not yet over, take a fresh
+ * snapshot of the idle-purr.
+ */
+ if (unlikely(get_lppaca()->idle == 1)) {
+ update_idle_purr_accounting();
+ snapshot_purr_idle_entry();
+ }
+
+ return be64_to_cpu(get_lppaca()->wait_state_cycles);
+}
+
I think this and read_this_idle_spurr() from the next patch should be moved
to Patch 4/6, where they are actually used.
The reason I included this function in this patch was to justify why
we were introducing snapshotting the purr values in a global per-cpu
variable instead of on a stack variable. The reason being that someone
might want to read the PURR value from an interrupt context which had
woken up the CPU from idle. At this point, since epilog() function
wasn't called, the idle PURR count corresponding to this latest idle
period would have been accumulated in lppaca->wait_cycles. Thus, this
helper function safely reads the value by
1) First updating the lppaca->wait_cycles with the latest idle_purr
count.
2) Take a fresh snapshot, since the time from now to the epilog()
call is also counted under idle CPU. So the PURR cycle increment
during this short period should also be accumulated in lppaca->wait_cycles.
prolog()
| snapshot PURR
|
|
|
Idle
|
| <----- Interrupt . Read idle PURR ---- update idle PURR;
| snapshot PURR;
| Read idle PURR.
|
epilog()
update idle PURR
- Naveen
However, if you feel that moving this function to Patch 4 where it is
actually used makes it more readable, I can do that.
--
Thanks and Regards
gautham.
From: Gautham R Shenoy <hidden> Date: 2020-04-03 06:37:42
Hi Naveen,
On Thu, Apr 02, 2020 at 01:04:34PM +0530, Naveen N. Rao wrote:
[..snip..]
quoted
It does reduce it to 10ms window. I am not sure if anyone samples PURR
etc faster than that rate.
I measured how much time it takes to read the purr, spurr, idle_purr,
idle_spurr files back-to-back. It takes not more than 150us. From
lparstat will these values be read back-to-back ? If so, we can reduce
the staleness_tolerance to something like 500us and still avoid extra
IPIs. If not, what is the maximum delay between the first sysfs file
read and the last sysfs file read ?
Oh, for lparstat usage, this is perfectly fine.
I meant that there could be other users of [s]purr who might care. I don't
know of one, but since this is an existing sysfs interface, I wanted to
point out that the behavior might change.
Fair point. Perhaps this should be documented in the Documentation, if
we are going to continue with this patch.
quoted
quoted
I wonder if we should introduce a sysctl interface to control thresholding.
It can default to 0, which disables thresholding so that the existing
behavior continues. Applications (lparstat) can optionally set it to suit
their use.
We would be introducing 3 new sysfs interfaces that way instead of
two.
/sys/devices/system/cpu/purr_spurr_staleness
/sys/devices/system/cpu/cpuX/idle_purr
/sys/devices/system/cpu/cpuX/idle_spurr
I don't have a problem with this. Nathan, Michael, thoughts on this?
The alternative is to have a procfs interface, something like
/proc/powerpc/resource_util_stats
which gives a listing similar to /proc/stat, i.e
CPUX <purr> <idle_purr> <spurr> <idle_spurr>
Even in this case, the values can be obtained in one-shot with a
single IPI and be printed in the row corresponding to the CPU.
Right -- and that would be optimal requiring a single system call, at the
cost of using a legacy interface.
The other option would be to drop this patch and to just go with patches 1-5
introducing the new sysfs interfaces for idle_[s]purr. It isn't entirely
clear how often this would be used, or its actual impact. We can perhaps
consider this optimization if and when this causes problems...
I am ok with that. We can revisit the problem if IPI noise becomes
noticable. However, if Nathan or Michael feel that this problem is
better solved now, than leaving it for the future, we will have to
take a call on what the interface is going to be.
From: Naveen N. Rao <hidden> Date: 2020-04-03 10:35:07
Gautham R Shenoy wrote:
On Wed, Apr 01, 2020 at 03:12:53PM +0530, Naveen N. Rao wrote:
quoted
Hi Gautham,
Gautham R. Shenoy wrote:
quoted
From: "Gautham R. Shenoy" <redacted>
+
+static inline u64 read_this_idle_purr(void)
+{
+ /*
+ * If we are reading from an idle context, update the
+ * idle-purr cycles corresponding to the last idle period.
+ * Since the idle context is not yet over, take a fresh
+ * snapshot of the idle-purr.
+ */
+ if (unlikely(get_lppaca()->idle == 1)) {
+ update_idle_purr_accounting();
+ snapshot_purr_idle_entry();
+ }
+
+ return be64_to_cpu(get_lppaca()->wait_state_cycles);
+}
+
I think this and read_this_idle_spurr() from the next patch should be moved
to Patch 4/6, where they are actually used.
The reason I included this function in this patch was to justify why
we were introducing snapshotting the purr values in a global per-cpu
variable instead of on a stack variable. The reason being that someone
might want to read the PURR value from an interrupt context which had
woken up the CPU from idle. At this point, since epilog() function
wasn't called, the idle PURR count corresponding to this latest idle
period would have been accumulated in lppaca->wait_cycles. Thus, this
helper function safely reads the value by
1) First updating the lppaca->wait_cycles with the latest idle_purr
count.
2) Take a fresh snapshot, since the time from now to the epilog()
call is also counted under idle CPU. So the PURR cycle increment
during this short period should also be accumulated in lppaca->wait_cycles.
prolog()
| snapshot PURR
|
|
|
Idle
|
| <----- Interrupt . Read idle PURR ---- update idle PURR;
| snapshot PURR;
| Read idle PURR.
|
epilog()
update idle PURR
Yes, I understand. It makes sense.
However, if you feel that moving this function to Patch 4 where it is
actually used makes it more readable, I can do that.
On Thu, Apr 02, 2020 at 01:04:34PM +0530, Naveen N. Rao wrote:
quoted
quoted
quoted
I wonder if we should introduce a sysctl interface to control thresholding.
It can default to 0, which disables thresholding so that the existing
behavior continues. Applications (lparstat) can optionally set it to suit
their use.
We would be introducing 3 new sysfs interfaces that way instead of
two.
/sys/devices/system/cpu/purr_spurr_staleness
/sys/devices/system/cpu/cpuX/idle_purr
/sys/devices/system/cpu/cpuX/idle_spurr
I don't have a problem with this. Nathan, Michael, thoughts on this?
No, I don't think this warrants a tunable when the issue it's intended
to address is still a bit speculative at this point. (Also, note that
this would be a system-wide value, but you could have multiple
concurrent users of the interface with different needs.)
quoted
quoted
The alternative is to have a procfs interface, something like
/proc/powerpc/resource_util_stats
which gives a listing similar to /proc/stat, i.e
CPUX <purr> <idle_purr> <spurr> <idle_spurr>
Even in this case, the values can be obtained in one-shot with a
single IPI and be printed in the row corresponding to the CPU.
Right -- and that would be optimal requiring a single system call, at the
cost of using a legacy interface.
The other option would be to drop this patch and to just go with patches 1-5
introducing the new sysfs interfaces for idle_[s]purr. It isn't entirely
clear how often this would be used, or its actual impact. We can perhaps
consider this optimization if and when this causes problems...
I am ok with that. We can revisit the problem if IPI noise becomes
noticable. However, if Nathan or Michael feel that this problem is
better solved now, than leaving it for the future, we will have to
take a call on what the interface is going to be.
While I maintain some concern about the overhead on larger LPARs (150us
per CPU works out to ~0.15s total to serially sample 1024 CPUs, ~0.3s
for 2048 and so on), I am OK with the straightforward addition of the
attributes without any batching or sampling thresholds behind the scenes
for now. I appreciate your consideration of the issue.
If this turns out to be too inefficient then I think we should consider
a non-sysfs mechanism such as chardev+ioctl.
From: Gautham R Shenoy <hidden> Date: 2020-04-06 04:57:20
On Fri, Apr 03, 2020 at 04:04:56PM +0530, Naveen N. Rao wrote:
Gautham R Shenoy wrote:
quoted
On Wed, Apr 01, 2020 at 03:12:53PM +0530, Naveen N. Rao wrote:
quoted
Hi Gautham,
Gautham R. Shenoy wrote:
quoted
From: "Gautham R. Shenoy" <redacted>
+
+static inline u64 read_this_idle_purr(void)
+{
+ /*
+ * If we are reading from an idle context, update the
+ * idle-purr cycles corresponding to the last idle period.
+ * Since the idle context is not yet over, take a fresh
+ * snapshot of the idle-purr.
+ */
+ if (unlikely(get_lppaca()->idle == 1)) {
+ update_idle_purr_accounting();
+ snapshot_purr_idle_entry();
+ }
+
+ return be64_to_cpu(get_lppaca()->wait_state_cycles);
+}
+
I think this and read_this_idle_spurr() from the next patch should be moved
to Patch 4/6, where they are actually used.
The reason I included this function in this patch was to justify why
we were introducing snapshotting the purr values in a global per-cpu
variable instead of on a stack variable. The reason being that someone
might want to read the PURR value from an interrupt context which had
woken up the CPU from idle. At this point, since epilog() function
wasn't called, the idle PURR count corresponding to this latest idle
period would have been accumulated in lppaca->wait_cycles. Thus, this
helper function safely reads the value by
1) First updating the lppaca->wait_cycles with the latest idle_purr
count.
2) Take a fresh snapshot, since the time from now to the epilog()
call is also counted under idle CPU. So the PURR cycle increment
during this short period should also be accumulated in lppaca->wait_cycles.
prolog()
| snapshot PURR
|
|
|
Idle
|
| <----- Interrupt . Read idle PURR ---- update idle PURR;
| snapshot PURR;
| Read idle PURR. |
epilog()
update idle PURR
Yes, I understand. It makes sense.
quoted
However, if you feel that moving this function to Patch 4 where it is
actually used makes it more readable, I can do that.