From: "Gautham R. Shenoy" <[email protected]>
Currently on Pseries Linux Guests, the offlined CPU can be put to one
of the following two states:
- Long term processor cede (also called extended cede)
- Returned to the Hypervisor via RTAS "stop-self" call.
This is controlled by the kernel boot parameter "cede_offline=on/off".
By default the offlined CPUs enter extended cede. The PHYP hypervisor
considers CPUs in extended cede to be "active" since the CPUs are
still under the control fo the Linux Guests. Hence, when we change the
SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
will continue to count the values for offlined CPUs in extended cede
as if they are online.
One of the expectations with PURR is that the for an interval of time,
the sum of the PURR increments across the online CPUs of a core should
equal the number of timebase ticks for that interval.
This is currently not the case.
In the following data (Generated using
https://github.com/gautshen/misc/blob/master/purr_tb.py):
delta tb = tb ticks elapsed in 1 second.
delta purr = sum of PURR increments on online CPUs of that core in 1
second
SMT=off
===========================================
Core delta tb(apprx) delta purr
===========================================
core00 [ 0] 512000000 69883784
core01 [ 8] 512000000 88782536
core02 [ 16] 512000000 94296824
core03 [ 24] 512000000 80951968
SMT=2
===========================================
Core delta tb(apprx) delta purr
===========================================
core00 [ 0,1] 512000000 136147792
core01 [ 8,9] 512000000 128636784
core02 [ 16,17] 512000000 135426488
core03 [ 24,25] 512000000 153027520
SMT=4
===================================================
Core delta tb(apprx) delta purr
===================================================
core00 [ 0,1,2,3] 512000000 258331616
core01 [ 8,9,10,11] 512000000 274220072
core02 [ 16,17,18,19] 512000000 260013736
core03 [ 24,25,26,27] 512000000 260079672
SMT=on
===================================================================
Core delta tb(apprx) delta purr
===================================================================
core00 [ 0,1,2,3,4,5,6,7] 512000000 512941248
core01 [ 8,9,10,11,12,13,14,15] 512000000 512936544
core02 [ 16,17,18,19,20,21,22,23] 512000000 512931544
core03 [ 24,25,26,27,28,29,30,31] 512000000 512923800
This patchset addresses this issue by ensuring that by default, the
offlined CPUs are returned to the Hypervisor via RTAS "stop-self" call
by changing the default value of "cede_offline_enabled" to false.
The patchset also defines a new sysfs attribute
"/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
to allow userspace programs to change the state into which the
offlined CPU need to be put to at runtime. This is intended for
userspace programs that fold CPUs for the purpose of saving energy
when the utilization is low. Setting the value of this attribute
ensures that subsequent CPU offline operations will put the offlined
CPUs to extended cede. However, it will cause inconsistencies in the
PURR accounting. Clearing the attribute will make the offlined CPUs
call the RTAS "stop-self" call thereby returning the CPU to the
hypervisor.
With the patches,
SMT=off
===========================================
Core delta tb(apprx) delta purr
===========================================
core00 [ 0] 512000000 512527568
core01 [ 8] 512000000 512556128
core02 [ 16] 512000000 512590016
core03 [ 24] 512000000 512589440
SMT=2
===========================================
Core delta tb(apprx) delta purr
===========================================
core00 [ 0,1] 512000000 512635328
core01 [ 8,9] 512000000 512610416
core02 [ 16,17] 512000000 512639360
core03 [ 24,25] 512000000 512638720
SMT=4
===================================================
Core delta tb(apprx) delta purr
===================================================
core00 [ 0,1,2,3] 512000000 512757328
core01 [ 8,9,10,11] 512000000 512727920
core02 [ 16,17,18,19] 512000000 512754712
core03 [ 24,25,26,27] 512000000 512739040
SMT=on
==============================================================
Core delta tb(apprx) delta purr
==============================================================
core00 [ 0,1,2,3,4,5,6,7] 512000000 512920936
core01 [ 8,9,10,11,12,13,14,15] 512000000 512878728
core02 [ 16,17,18,19,20,21,22,23] 512000000 512921192
core03 [ 24,25,26,27,28,29,30,31] 512000000 512924816
Gautham R. Shenoy (2):
pseries/hotplug-cpu: Change default behaviour of cede_offline to "off"
pseries/hotplug-cpu: Add sysfs attribute for cede_offline
Documentation/ABI/testing/sysfs-devices-system-cpu | 14 ++++
Documentation/core-api/cpu_hotplug.rst | 2 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 80 ++++++++++++++++++++--
3 files changed, 88 insertions(+), 8 deletions(-)
--
1.9.4
"Gautham R. Shenoy" <[email protected]> writes:
> The patchset also defines a new sysfs attribute
> "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> to allow userspace programs to change the state into which the
> offlined CPU need to be put to at runtime.
A boolean sysfs interface will become awkward if we need to add another
mode in the future.
What do you think about naming the attribute something like
'offline_mode', with the possible values 'extended-cede' and
'rtas-stopped'?
Hello Nathan,
On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
> "Gautham R. Shenoy" <[email protected]> writes:
> > The patchset also defines a new sysfs attribute
> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> > to allow userspace programs to change the state into which the
> > offlined CPU need to be put to at runtime.
>
> A boolean sysfs interface will become awkward if we need to add another
> mode in the future.
>
> What do you think about naming the attribute something like
> 'offline_mode', with the possible values 'extended-cede' and
> 'rtas-stopped'?
We can do that. However, IMHO in the longer term, on PSeries guests,
we should have only one offline state - rtas-stopped. The reason for
this being, that on Linux, SMT switch is brought into effect through
the CPU Hotplug interface. The only state in which the SMT switch will
recognized by the hypervisors such as PHYP is rtas-stopped.
All other states (such as extended-cede) should in the long-term be
exposed via the cpuidle interface.
With this in mind, I made the sysfs interface boolean to mirror the
current "cede_offline" commandline parameter. Eventually when we have
only one offline-state, we can deprecate the commandline parameter as
well as the sysfs interface.
Thoughts?
--
Thanks and Regards
gautham.
Gautham R Shenoy <[email protected]> writes:
> On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
>> "Gautham R. Shenoy" <[email protected]> writes:
>> > The patchset also defines a new sysfs attribute
>> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
>> > to allow userspace programs to change the state into which the
>> > offlined CPU need to be put to at runtime.
>>
>> A boolean sysfs interface will become awkward if we need to add another
>> mode in the future.
>>
>> What do you think about naming the attribute something like
>> 'offline_mode', with the possible values 'extended-cede' and
>> 'rtas-stopped'?
>
> We can do that. However, IMHO in the longer term, on PSeries guests,
> we should have only one offline state - rtas-stopped. The reason for
> this being, that on Linux, SMT switch is brought into effect through
> the CPU Hotplug interface. The only state in which the SMT switch will
> recognized by the hypervisors such as PHYP is rtas-stopped.
OK. Why "longer term" though, instead of doing it now?
> All other states (such as extended-cede) should in the long-term be
> exposed via the cpuidle interface.
>
> With this in mind, I made the sysfs interface boolean to mirror the
> current "cede_offline" commandline parameter. Eventually when we have
> only one offline-state, we can deprecate the commandline parameter as
> well as the sysfs interface.
I don't care for adding a sysfs interface that is intended from the
beginning to become vestigial...
This strikes me as unnecessarily incremental if you're changing the
default offline state. Any user space programs depending on the current
behavior will have to change anyway (and why is it OK to break them?)
Why isn't the plan:
1. Add extended cede support to the pseries cpuidle driver
2. Make stop-self the only cpu offline state for pseries (no sysfs
interface necessary)
?
"Gautham R. Shenoy" <[email protected]> writes:
> From: "Gautham R. Shenoy" <[email protected]>
>
> Currently on Pseries Linux Guests, the offlined CPU can be put to one
> of the following two states:
> - Long term processor cede (also called extended cede)
> - Returned to the Hypervisor via RTAS "stop-self" call.
>
> This is controlled by the kernel boot parameter "cede_offline=on/off".
>
> By default the offlined CPUs enter extended cede.
Since commit 3aa565f53c39 ("powerpc/pseries: Add hooks to put the CPU into an appropriate offline state") (Nov 2009)
Which you wrote :)
Why was that wrong?
> The PHYP hypervisor considers CPUs in extended cede to be "active"
> since the CPUs are still under the control fo the Linux Guests. Hence, when we change the
> SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
> will continue to count the values for offlined CPUs in extended cede
> as if they are online.
>
> One of the expectations with PURR is that the for an interval of time,
> the sum of the PURR increments across the online CPUs of a core should
> equal the number of timebase ticks for that interval.
>
> This is currently not the case.
But why does that matter? It's just some accounting stuff, does it
actually break something meaningful?
Also what does this do to the latency of CPU online/offline.
And what does this do on KVM?
> In the following data (Generated using
> https://github.com/gautshen/misc/blob/master/purr_tb.py):
>
>
> delta tb = tb ticks elapsed in 1 second.
> delta purr = sum of PURR increments on online CPUs of that core in 1
> second
>
> SMT=off
> ===========================================
> Core delta tb(apprx) delta purr
> ===========================================
> core00 [ 0] 512000000 69883784
> core01 [ 8] 512000000 88782536
> core02 [ 16] 512000000 94296824
> core03 [ 24] 512000000 80951968
Showing the expected value in another column would make this much
clearer.
cheers
> SMT=2
> ===========================================
> Core delta tb(apprx) delta purr
> ===========================================
> core00 [ 0,1] 512000000 136147792
> core01 [ 8,9] 512000000 128636784
> core02 [ 16,17] 512000000 135426488
> core03 [ 24,25] 512000000 153027520
>
> SMT=4
> ===================================================
> Core delta tb(apprx) delta purr
> ===================================================
> core00 [ 0,1,2,3] 512000000 258331616
> core01 [ 8,9,10,11] 512000000 274220072
> core02 [ 16,17,18,19] 512000000 260013736
> core03 [ 24,25,26,27] 512000000 260079672
>
> SMT=on
> ===================================================================
> Core delta tb(apprx) delta purr
> ===================================================================
> core00 [ 0,1,2,3,4,5,6,7] 512000000 512941248
> core01 [ 8,9,10,11,12,13,14,15] 512000000 512936544
> core02 [ 16,17,18,19,20,21,22,23] 512000000 512931544
> core03 [ 24,25,26,27,28,29,30,31] 512000000 512923800
>
> This patchset addresses this issue by ensuring that by default, the
> offlined CPUs are returned to the Hypervisor via RTAS "stop-self" call
> by changing the default value of "cede_offline_enabled" to false.
>
> The patchset also defines a new sysfs attribute
> "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> to allow userspace programs to change the state into which the
> offlined CPU need to be put to at runtime. This is intended for
> userspace programs that fold CPUs for the purpose of saving energy
> when the utilization is low. Setting the value of this attribute
> ensures that subsequent CPU offline operations will put the offlined
> CPUs to extended cede. However, it will cause inconsistencies in the
> PURR accounting. Clearing the attribute will make the offlined CPUs
> call the RTAS "stop-self" call thereby returning the CPU to the
> hypervisor.
>
> With the patches,
>
> SMT=off
> ===========================================
> Core delta tb(apprx) delta purr
> ===========================================
> core00 [ 0] 512000000 512527568
> core01 [ 8] 512000000 512556128
> core02 [ 16] 512000000 512590016
> core03 [ 24] 512000000 512589440
>
> SMT=2
> ===========================================
> Core delta tb(apprx) delta purr
> ===========================================
> core00 [ 0,1] 512000000 512635328
> core01 [ 8,9] 512000000 512610416
> core02 [ 16,17] 512000000 512639360
> core03 [ 24,25] 512000000 512638720
>
> SMT=4
> ===================================================
> Core delta tb(apprx) delta purr
> ===================================================
> core00 [ 0,1,2,3] 512000000 512757328
> core01 [ 8,9,10,11] 512000000 512727920
> core02 [ 16,17,18,19] 512000000 512754712
> core03 [ 24,25,26,27] 512000000 512739040
>
> SMT=on
> ==============================================================
> Core delta tb(apprx) delta purr
> ==============================================================
> core00 [ 0,1,2,3,4,5,6,7] 512000000 512920936
> core01 [ 8,9,10,11,12,13,14,15] 512000000 512878728
> core02 [ 16,17,18,19,20,21,22,23] 512000000 512921192
> core03 [ 24,25,26,27,28,29,30,31] 512000000 512924816
>
> Gautham R. Shenoy (2):
> pseries/hotplug-cpu: Change default behaviour of cede_offline to "off"
> pseries/hotplug-cpu: Add sysfs attribute for cede_offline
>
> Documentation/ABI/testing/sysfs-devices-system-cpu | 14 ++++
> Documentation/core-api/cpu_hotplug.rst | 2 +-
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 80 ++++++++++++++++++++--
> 3 files changed, 88 insertions(+), 8 deletions(-)
>
> --
> 1.9.4
Nathan Lynch <[email protected]> writes:
> Gautham R Shenoy <[email protected]> writes:
>> On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
>>> "Gautham R. Shenoy" <[email protected]> writes:
>>> > The patchset also defines a new sysfs attribute
>>> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
>>> > to allow userspace programs to change the state into which the
>>> > offlined CPU need to be put to at runtime.
>>>
>>> A boolean sysfs interface will become awkward if we need to add another
>>> mode in the future.
>>>
>>> What do you think about naming the attribute something like
>>> 'offline_mode', with the possible values 'extended-cede' and
>>> 'rtas-stopped'?
>>
>> We can do that. However, IMHO in the longer term, on PSeries guests,
>> we should have only one offline state - rtas-stopped. The reason for
>> this being, that on Linux, SMT switch is brought into effect through
>> the CPU Hotplug interface. The only state in which the SMT switch will
>> recognized by the hypervisors such as PHYP is rtas-stopped.
>
> OK. Why "longer term" though, instead of doing it now?
>
>
>> All other states (such as extended-cede) should in the long-term be
>> exposed via the cpuidle interface.
>>
>> With this in mind, I made the sysfs interface boolean to mirror the
>> current "cede_offline" commandline parameter. Eventually when we have
>> only one offline-state, we can deprecate the commandline parameter as
>> well as the sysfs interface.
>
> I don't care for adding a sysfs interface that is intended from the
> beginning to become vestigial...
>
> This strikes me as unnecessarily incremental if you're changing the
> default offline state. Any user space programs depending on the current
> behavior will have to change anyway (and why is it OK to break them?)
>
> Why isn't the plan:
>
> 1. Add extended cede support to the pseries cpuidle driver
> 2. Make stop-self the only cpu offline state for pseries (no sysfs
> interface necessary)
I agree, that would be preferable. Adding more sysfs tunables sucks,
especially if they're going to be deprecated in the not too distant
future.
Another option would be to add extended cede to the cpuidle driver,
and retain the cede_offline boot parameter but make it false by default.
cheers
Michael Ellerman wrote:
> "Gautham R. Shenoy" <[email protected]> writes:
>> From: "Gautham R. Shenoy" <[email protected]>
>>
>> Currently on Pseries Linux Guests, the offlined CPU can be put to one
>> of the following two states:
>> - Long term processor cede (also called extended cede)
>> - Returned to the Hypervisor via RTAS "stop-self" call.
>>
>> This is controlled by the kernel boot parameter "cede_offline=on/off".
>>
>> By default the offlined CPUs enter extended cede.
>
> Since commit 3aa565f53c39 ("powerpc/pseries: Add hooks to put the CPU into an appropriate offline state") (Nov 2009)
>
> Which you wrote :)
>
> Why was that wrong?
>
>> The PHYP hypervisor considers CPUs in extended cede to be "active"
>> since the CPUs are still under the control fo the Linux Guests. Hence, when we change the
>> SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
>> will continue to count the values for offlined CPUs in extended cede
>> as if they are online.
>>
>> One of the expectations with PURR is that the for an interval of time,
>> the sum of the PURR increments across the online CPUs of a core should
>> equal the number of timebase ticks for that interval.
>>
>> This is currently not the case.
>
> But why does that matter? It's just some accounting stuff, does it
> actually break something meaningful?
Yes, this broke lparstat at the very least (though its quite unfortunate
we took so long to notice).
With SMT disabled, and under load:
$ sudo lparstat 1 10
System Configuration
type=Shared mode=Uncapped smt=Off lcpu=2 mem=7759616 kB cpus=6 ent=1.00
%user %sys %wait %idle physc %entc lbusy vcsw phint
----- ----- ----- ----- ----- ----- ----- ----- -----
100.00 0.00 0.00 0.00 1.10 110.00 100.00 128784460 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128784860 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128785260 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128785662 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786062 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786462 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786862 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128787262 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128787664 0
100.00 0.00 0.00 0.00 1.07 107.00 100.00 128788064 0
With cede_offline=off:
$ sudo lparstat 1 10
System Configuration
type=Shared mode=Uncapped smt=Off lcpu=2 mem=7759616 kB cpus=6 ent=1.00
%user %sys %wait %idle physc %entc lbusy vcsw phint
----- ----- ----- ----- ----- ----- ----- ----- -----
100.00 0.00 0.00 0.00 1.94 194.00 100.00 128961588 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128961988 0
100.00 0.00 0.00 0.00 inf inf 100.00 128962392 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128962792 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963192 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963592 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963992 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128964392 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128964792 0
100.00 0.00 0.00 0.00 1.91 191.00 100.00 128965194 0
[The 'inf' values there show a different bug]
Also, since we expose [S]PURR through sysfs, any tools that make use of
that directly are also affected due to this.
- Naveen
Hello Nathan, Michael,
On Tue, Sep 17, 2019 at 12:36:35PM -0500, Nathan Lynch wrote:
> Gautham R Shenoy <[email protected]> writes:
> > On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote:
> >> "Gautham R. Shenoy" <[email protected]> writes:
> >> > The patchset also defines a new sysfs attribute
> >> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> >> > to allow userspace programs to change the state into which the
> >> > offlined CPU need to be put to at runtime.
> >>
> >> A boolean sysfs interface will become awkward if we need to add another
> >> mode in the future.
> >>
> >> What do you think about naming the attribute something like
> >> 'offline_mode', with the possible values 'extended-cede' and
> >> 'rtas-stopped'?
> >
> > We can do that. However, IMHO in the longer term, on PSeries guests,
> > we should have only one offline state - rtas-stopped. The reason for
> > this being, that on Linux, SMT switch is brought into effect through
> > the CPU Hotplug interface. The only state in which the SMT switch will
> > recognized by the hypervisors such as PHYP is rtas-stopped.
>
> OK. Why "longer term" though, instead of doing it now?
Because adding extended-cede into a cpuidle state is non-trivial since
a CPU in that state is non responsive to external interrupts. We will
additional changes in the IPI, Timer and the Interrupt code to ensure
that these get translated to a H_PROD in order to wake-up the target
CPU in extended CEDE.
Timer: is relatively easy since the cpuidle infrastructure has the
timer-offload framework (used for fastsleep in POWER8) where we
can offload the timers of an idling CPU to another CPU which
can wakeup the CPU when the timer expires via an IPI.
IPIs: We need to ensure that icp_hv_set_qirr() correctly sends H_IPI
or H_PROD depending on whether or not the target CPU is in
extended CEDE.
Interrupts: Either we migrate away the interrupts from the CPU that is
entering extended CEDE or we prevent a CPU that is the
sole target for an interrupt from entering extended CEDE.
The accounting problem in tools such as lparstat with
"cede_offline=on" is affecting customers who are using these tools for
capacity-planning. That problem needs a fix in the short-term, for
which Patch 1 changes the default behaviour of cede_offline from "on"
to "off". Since this patch would break the existing userspace tools
that use the CPU-Offline infrastructure to fold CPUs for saving power,
the sysfs interface allowing a runtime change of cede_offline_enabled
was provided to enable these userspace tools to cope with minimal
change.
>
>
> > All other states (such as extended-cede) should in the long-term be
> > exposed via the cpuidle interface.
> >
> > With this in mind, I made the sysfs interface boolean to mirror the
> > current "cede_offline" commandline parameter. Eventually when we have
> > only one offline-state, we can deprecate the commandline parameter as
> > well as the sysfs interface.
>
> I don't care for adding a sysfs interface that is intended from the
> beginning to become vestigial...
Fair point. Come to think of it, in case the cpuidle menu governor
behaviour doesn't match the expectations provided by the current
userspace solutions for folding idle CPUs for power-savings, it would
be useful to have this option around so that existing users who prefer
the userspace solution can still have that option.
>
> This strikes me as unnecessarily incremental if you're changing the
> default offline state. Any user space programs depending on the current
> behavior will have to change anyway (and why is it OK to break them?)
>
Yes, the current userspace program will need to be modified to check
for the sysfs interface and change the value to
cede_offline_enabled=1.
> Why isn't the plan:
>
> 1. Add extended cede support to the pseries cpuidle driver
> 2. Make stop-self the only cpu offline state for pseries (no sysfs
> interface necessary)
This is the plan, except that 1. requires some additional work and
this patchset is proposed as a short-term mitigation until we get
1. right.
>
> ?
--
Thanks and Regards
gautham.
On Wed, Sep 18, 2019 at 03:14:15PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <[email protected]> writes:
> > From: "Gautham R. Shenoy" <[email protected]>
> >
> > Currently on Pseries Linux Guests, the offlined CPU can be put to one
> > of the following two states:
> > - Long term processor cede (also called extended cede)
> > - Returned to the Hypervisor via RTAS "stop-self" call.
> >
> > This is controlled by the kernel boot parameter "cede_offline=on/off".
> >
> > By default the offlined CPUs enter extended cede.
>
> Since commit 3aa565f53c39 ("powerpc/pseries: Add hooks to put the CPU into an appropriate offline state") (Nov 2009)
>
> Which you wrote :)
Mea Culpa! I forgot to include the "Fixes commit 3aa565f53c39" into
Patch 1 of the series.
>
> Why was that wrong?
It was wrong from the definition of what PHYP considers as
"not-active" CPU. From the point of view of that hypervisor, a CPU is
not-active iff it is in RTAS "stop-self". Thus if a CPU is offline via
extended cede, and not using any cycles, it is still considered to be
active, by PHYP. This causes PURR accounting is broken.
>
> > The PHYP hypervisor considers CPUs in extended cede to be "active"
> > since the CPUs are still under the control fo the Linux Guests. Hence, when we change the
> > SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
> > will continue to count the values for offlined CPUs in extended cede
> > as if they are online.
> >
> > One of the expectations with PURR is that the for an interval of time,
> > the sum of the PURR increments across the online CPUs of a core should
> > equal the number of timebase ticks for that interval.
> >
> > This is currently not the case.
>
> But why does that matter? It's just some accounting stuff, does it
> actually break something meaningful?
As Naveen mentioned, it breaks lparstat which the customers are using
for capacity planning. Unfortunately we discovered this 10 years after
the feature was written.
>
> Also what does this do to the latency of CPU online/offline.
It will have a slightly higher latency compared to extended cede,
since it involves an additional rtas-call for both the start and
stopping of CPU. Will measure the exact difference and post it in the
next version.
> And what does this do on KVM?
KVM doesn't seem to depend on the state of the offline VCPU as it has
an explicit way of signalling whether a CPU is online or not, via
KVM_REG_PPC_ONLINE. In commit 7aa15842c15f ("KVM: PPC: Book3S HV: Set
RWMR on POWER8 so PURR/SPURR count correctly") we use this KVM reg to
update the count of online vCPUs in a core, and use this count to set
the RWMR correctly before dispatching the core.
So, this patchset doesn't affect KVM.
>
>
> > In the following data (Generated using
> > https://github.com/gautshen/misc/blob/master/purr_tb.py):
> >
> >
> > delta tb = tb ticks elapsed in 1 second.
> > delta purr = sum of PURR increments on online CPUs of that core in 1
> > second
> >
> > SMT=off
> > ===========================================
> > Core delta tb(apprx) delta purr
> > ===========================================
> > core00 [ 0] 512000000 69883784
> > core01 [ 8] 512000000 88782536
> > core02 [ 16] 512000000 94296824
> > core03 [ 24] 512000000 80951968
>
> Showing the expected value in another column would make this much
> clearer.
Thanks. Will update the testcase to call out the expected value.
>
> cheers
>
--
Thanks and Regards
gautham.
On 9/18/19 5:01 PM, Michael Ellerman wrote:
> "Naveen N. Rao" <[email protected]> writes:
>> Michael Ellerman wrote:
>>> "Gautham R. Shenoy" <[email protected]> writes:
>>>> From: "Gautham R. Shenoy" <[email protected]>
>
....
>> Also, since we expose [S]PURR through sysfs, any tools that make use of
>> that directly are also affected due to this.
>
> But again if we've had the current behaviour for 10 years then arguably
> that's now the correct behaviour.
Or nobody is looking at PURR based accounting/usage metric on Linux. We
got some customers complaining about this recently once they started
using the metric.
-aneesh
"Naveen N. Rao" <[email protected]> writes:
> Michael Ellerman wrote:
>> "Gautham R. Shenoy" <[email protected]> writes:
>>> From: "Gautham R. Shenoy" <[email protected]>
>>>
>>> Currently on Pseries Linux Guests, the offlined CPU can be put to one
>>> of the following two states:
>>> - Long term processor cede (also called extended cede)
>>> - Returned to the Hypervisor via RTAS "stop-self" call.
>>>
>>> This is controlled by the kernel boot parameter "cede_offline=on/off".
>>>
>>> By default the offlined CPUs enter extended cede.
>>
>> Since commit 3aa565f53c39 ("powerpc/pseries: Add hooks to put the CPU into an appropriate offline state") (Nov 2009)
>>
>> Which you wrote :)
>>
>> Why was that wrong?
>>
>>> The PHYP hypervisor considers CPUs in extended cede to be "active"
>>> since the CPUs are still under the control fo the Linux Guests. Hence, when we change the
>>> SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
>>> will continue to count the values for offlined CPUs in extended cede
>>> as if they are online.
>>>
>>> One of the expectations with PURR is that the for an interval of time,
>>> the sum of the PURR increments across the online CPUs of a core should
>>> equal the number of timebase ticks for that interval.
>>>
>>> This is currently not the case.
>>
>> But why does that matter? It's just some accounting stuff, does it
>> actually break something meaningful?
>
> Yes, this broke lparstat at the very least (though its quite unfortunate
> we took so long to notice).
By "so long" you mean 10 years?
Also I've never heard of lparstat, but I assume it's one of these tools
that's meant to behave like the AIX equivalent?
If it's been "broken" for 10 years and no one noticed, I'd argue the
current behaviour is now "correct" and fixing it would actually be a
breakage :)
> With SMT disabled, and under load:
> $ sudo lparstat 1 10
>
> System Configuration
> type=Shared mode=Uncapped smt=Off lcpu=2 mem=7759616 kB cpus=6 ent=1.00
>
> %user %sys %wait %idle physc %entc lbusy vcsw phint
> ----- ----- ----- ----- ----- ----- ----- ----- -----
> 100.00 0.00 0.00 0.00 1.10 110.00 100.00 128784460 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128784860 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128785260 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128785662 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786062 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786462 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786862 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128787262 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128787664 0
> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128788064 0
What about that is wrong?
> With cede_offline=off:
> $ sudo lparstat 1 10
>
> System Configuration
> type=Shared mode=Uncapped smt=Off lcpu=2 mem=7759616 kB cpus=6 ent=1.00
>
> %user %sys %wait %idle physc %entc lbusy vcsw phint
> ----- ----- ----- ----- ----- ----- ----- ----- -----
> 100.00 0.00 0.00 0.00 1.94 194.00 100.00 128961588 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128961988 0
> 100.00 0.00 0.00 0.00 inf inf 100.00 128962392 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128962792 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963192 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963592 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963992 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128964392 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128964792 0
> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128965194 0
>
> [The 'inf' values there show a different bug]
>
> Also, since we expose [S]PURR through sysfs, any tools that make use of
> that directly are also affected due to this.
But again if we've had the current behaviour for 10 years then arguably
that's now the correct behaviour.
cheers
Gautham R Shenoy <[email protected]> writes:
> The accounting problem in tools such as lparstat with
> "cede_offline=on" is affecting customers who are using these tools for
> capacity-planning. That problem needs a fix in the short-term, for
> which Patch 1 changes the default behaviour of cede_offline from "on"
> to "off". Since this patch would break the existing userspace tools
> that use the CPU-Offline infrastructure to fold CPUs for saving power,
> the sysfs interface allowing a runtime change of cede_offline_enabled
> was provided to enable these userspace tools to cope with minimal
> change.
So we would be putting users in the position of choosing between folding
and correct accounting. :-(
Actually how does changing the offline mechanism to stop-self break the
folding utility?
Michael Ellerman wrote:
> "Naveen N. Rao" <[email protected]> writes:
>> Michael Ellerman wrote:
>>> "Gautham R. Shenoy" <[email protected]> writes:
>>>> From: "Gautham R. Shenoy" <[email protected]>
>>>>
>>>> Currently on Pseries Linux Guests, the offlined CPU can be put to one
>>>> of the following two states:
>>>> - Long term processor cede (also called extended cede)
>>>> - Returned to the Hypervisor via RTAS "stop-self" call.
>>>>
>>>> This is controlled by the kernel boot parameter "cede_offline=on/off".
>>>>
>>>> By default the offlined CPUs enter extended cede.
>>>
>>> Since commit 3aa565f53c39 ("powerpc/pseries: Add hooks to put the CPU into an appropriate offline state") (Nov 2009)
>>>
>>> Which you wrote :)
>>>
>>> Why was that wrong?
>>>
>>>> The PHYP hypervisor considers CPUs in extended cede to be "active"
>>>> since the CPUs are still under the control fo the Linux Guests. Hence, when we change the
>>>> SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
>>>> will continue to count the values for offlined CPUs in extended cede
>>>> as if they are online.
>>>>
>>>> One of the expectations with PURR is that the for an interval of time,
>>>> the sum of the PURR increments across the online CPUs of a core should
>>>> equal the number of timebase ticks for that interval.
>>>>
>>>> This is currently not the case.
>>>
>>> But why does that matter? It's just some accounting stuff, does it
>>> actually break something meaningful?
>>
>> Yes, this broke lparstat at the very least (though its quite unfortunate
>> we took so long to notice).
>
> By "so long" you mean 10 years?
>
> Also I've never heard of lparstat, but I assume it's one of these tools
> that's meant to behave like the AIX equivalent?
Yes, and yes. lparstat is part of powerpc-utils.
>
> If it's been "broken" for 10 years and no one noticed, I'd argue the
> current behaviour is now "correct" and fixing it would actually be a
> breakage :)
:)
More on this below...
>
>> With SMT disabled, and under load:
>> $ sudo lparstat 1 10
>>
>> System Configuration
>> type=Shared mode=Uncapped smt=Off lcpu=2 mem=7759616 kB cpus=6 ent=1.00
>>
>> %user %sys %wait %idle physc %entc lbusy vcsw phint
>> ----- ----- ----- ----- ----- ----- ----- ----- -----
>> 100.00 0.00 0.00 0.00 1.10 110.00 100.00 128784460 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128784860 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128785260 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128785662 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786062 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786462 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128786862 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128787262 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128787664 0
>> 100.00 0.00 0.00 0.00 1.07 107.00 100.00 128788064 0
>
> What about that is wrong?
The 'physc' column represents cpu usage in units of physical cores.
With 2 virtual cores ('lcpu=2') in uncapped, shared processor mode, we
expect this to be closer to 2 when fully loaded (and spare capacity
elsewhere in the system).
>
>> With cede_offline=off:
>> $ sudo lparstat 1 10
>>
>> System Configuration
>> type=Shared mode=Uncapped smt=Off lcpu=2 mem=7759616 kB cpus=6 ent=1.00
>>
>> %user %sys %wait %idle physc %entc lbusy vcsw phint
>> ----- ----- ----- ----- ----- ----- ----- ----- -----
>> 100.00 0.00 0.00 0.00 1.94 194.00 100.00 128961588 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128961988 0
>> 100.00 0.00 0.00 0.00 inf inf 100.00 128962392 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128962792 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963192 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963592 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128963992 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128964392 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128964792 0
>> 100.00 0.00 0.00 0.00 1.91 191.00 100.00 128965194 0
>>
>> [The 'inf' values there show a different bug]
>>
>> Also, since we expose [S]PURR through sysfs, any tools that make use of
>> that directly are also affected due to this.
>
> But again if we've had the current behaviour for 10 years then arguably
> that's now the correct behaviour.
That's a fair point, and probably again points to this area getting less
tested. One of the main reasons for this being caught now though, is
that there are workloads being tested under lower SMT levels now. So, I
suspect no one has been relying on this behavior and we can consider
this to be a bug.
Thanks,
Naveen