From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:11:18
This patchset intends to add frequency throttle reporting mechanism
to powernv-cpufreq driver when OCC throttles the frequency. OCC is an
On-Chip-Controller which takes care of the power and thermal safety of
the chip. The CPU frequency can be throttled during an OCC reset or
when OCC tries to limit the max allowed frequency. The patchset will
report such conditions so as to keep the user informed about reason
for the drop in performance of workloads when frequency is throttled.
Changes from v3:
- Rebased on top of 4.2-rc1
- Minor changes in patch 2,3,4,6 this does not change the
functionality of the code
- 594fcb9ec9e powerpc/powernv: Expose OPAL APIs required by PRD
interface , this patch fixes the build error due to which this
series was initially dropped
ERROR: ".opal_message_notifier_register"
drivers/cpufreq/powernv-cpufreq.ko] undefined!
Changes from v2:
- Split into multiple patches
- Semantic fixes
Shilpasri G Bhat (6):
cpufreq: powernv: Handle throttling due to Pmax capping at chip level
powerpc/powernv: Add definition of OPAL_MSG_OCC message type
cpufreq: powernv: Register for OCC related opal_message notification
cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE
cpufreq: powernv: Report Psafe only if PMSR.psafe_mode_active bit is
set
cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling
arch/powerpc/include/asm/opal-api.h | 12 +++
drivers/cpufreq/powernv-cpufreq.c | 195 +++++++++++++++++++++++++++++++++---
2 files changed, 192 insertions(+), 15 deletions(-)
--
1.9.3
From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:11:23
The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
max allowed frequency for that chip if the chip exceeds its power or
temperature limits. As Pmax capping is a chip level condition report
this throttling behavior at chip level and also do not set the global
'throttled' on Pmax capping instead set the per-chip throttled
variable. Report unthrottling if Pmax is restored after throttling.
This patch adds a structure to store chip id and throttled state of
the chip.
Signed-off-by: Shilpasri G Bhat <redacted>
Reviewed-by: Preeti U Murthy <redacted>
---
No change from v3
drivers/cpufreq/powernv-cpufreq.c | 59 ++++++++++++++++++++++++++++++++++++---
1 file changed, 55 insertions(+), 4 deletions(-)
@@ -301,22 +309,33 @@ static inline unsigned int get_nominal_index(void)staticvoidpowernv_cpufreq_throttle_check(unsignedintcpu){unsignedlongpmsr;-intpmsr_pmax,pmsr_lp;+intpmsr_pmax,pmsr_lp,i;pmsr=get_pmspr(SPRN_PMSR);+for(i=0;i<nr_chips;i++)+if(chips[i].id==cpu_to_chip_id(cpu))+break;+/* Check for Pmax Capping */pmsr_pmax=(s8)PMSR_MAX(pmsr);if(pmsr_pmax!=powernv_pstate_info.max){-throttled=true;-pr_info("CPU %d Pmax is reduced to %d\n",cpu,pmsr_pmax);-pr_info("Max allowed Pstate is capped\n");+if(chips[i].throttled)+gotonext;+chips[i].throttled=true;+pr_info("CPU %d on Chip %u has Pmax reduced to %d\n",cpu,+chips[i].id,pmsr_pmax);+}elseif(chips[i].throttled){+chips[i].throttled=false;+pr_info("CPU %d on Chip %u has Pmax restored to %d\n",cpu,+chips[i].id,pmsr_pmax);}/**CheckforPsafebyreadingLocalPstate*orcheckifPsafe_mode_activeissetinPMSR.*/+next:pmsr_lp=(s8)PMSR_LP(pmsr);if((pmsr_lp<powernv_pstate_info.min)||(pmsr&PMSR_PSAFE_ENABLE)){
From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:11:27
Add OPAL_MSG_OCC message definition to opal_message_type to receive
OCC events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles the max Pstate.
We can register to opal_message_notifier to receive OPAL_MSG_OCC type
of message and report it to the userspace so as to keep the user
informed about the reason for a performance drop in workloads.
The reset and load OCC events are notified to kernel when FSP sends
OCC_RESET and OCC_LOAD commands. Both reset and load messages are
sent to kernel on successful completion of reset and load operation
respectively.
The throttle OCC event indicates that the Pmax of the chip is reduced.
The chip_id and throttle reason for reducing Pmax is also queued along
with the message.
CC: Stewart Smith <redacted>
Signed-off-by: Shilpasri G Bhat <redacted>
---
Changes from v3:
- '0d7cd8550d3 powerpc/powernv: Add opal-prd channel' this patch adds
the definition of OPAL_MSG_PRD, so remove it and update the
changelog.
- Move the definitions of OCC_RESET, OCC_LOAD and OCC_THROTTLE from
drivers/cpufreq/powernv-cpufreq.c to arch/powerpc/include/asm/opal-api.h
- Define OCC_MAX_THROTTLE_STATUS
- Add a wrapper structure 'opal_occ_msg' to copy 'struct opal_msg.params[0..2]'
This structure will define the parameters received from firmware to
maintain compatibility for any future additions.
No change from v2
Change from v1:
- Update the commit changelog
arch/powerpc/include/asm/opal-api.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:11:30
OCC is an On-Chip-Controller which takes care of power and thermal
safety of the chip. During runtime due to power failure or
overtemperature the OCC may throttle the frequencies of the CPUs to
remain within the power budget.
We want the cpufreq driver to be aware of such situations to be able
to report the reason to the user. We register to opal_message_notifier
to receive OCC messages from opal.
powernv_cpufreq_throttle_check() reports any frequency throttling and
this patch will report the reason or event that caused throttling. We
can be throttled if OCC is reset or OCC limits Pmax due to power or
thermal reasons. We are also notified of unthrottling after an OCC
reset or if OCC restores Pmax on the chip.
Signed-off-by: Shilpasri G Bhat <redacted>
---
Changes from v3:
- Move the macro definitions of OCC_RESET, OCC_LOAD, OCC_THROTTLE to
arch/powerpc/include/asm/opal-api.h
- Use 'struct opal_occ_msg' to copy the 'opal_msg->params[]' and refer
the members of this structure in the code; Replace 'chip_id',
'token' and 'reason' with omsg.chip, omsg.type, omsg.throttle_status
- Use OCC_MAX_THROTTLE_STATUS instead of the magic number.
- Add opal_message_notifier_unregister()
Changes from v2:
- Patch split in to multiple patches.
- This patch contains only the opal_message notification handler
Changes from v1:
- Add macros to define OCC_RESET, OCC_LOAD and OCC_THROTTLE
- Define a structure to store chip id, chip mask which has bits set
for cpus present in the chip, throttled state and a work_struct.
- Modify powernv_cpufreq_throttle_check() to be called via smp_call()
- On Pmax throttling/unthrottling update 'chip.throttled' and not the
global 'throttled' as Pmax capping is local to the chip.
- Remove the condition which checks if local pstate is less than Pmin
while checking for Psafe frequency. When OCC becomes active after
reset we update 'thottled' to false and when the cpufreq governor
initiates a pstate change, the local pstate will be in Psafe and we
will be reporting a false positive when we are not throttled.
- Schedule a kworker on receiving throttling/unthrottling OCC message
for that chip and schedule on all chips after receiving active.
- After an OCC reset all the cpus will be in Psafe frequency. So call
target() and restore the frequency to policy->cur after OCC_ACTIVE
and Pmax unthrottling
- Taken care of Viresh and Preeti's comments.
drivers/cpufreq/powernv-cpufreq.c | 71 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 70 insertions(+), 1 deletion(-)
From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:11:31
Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
notification by executing *throttle_check() on any one of the cpu on
the chip. This is a sanity check to verify if we were indeed
throttled/unthrottled after receiving OCC_THROTTLE notification.
We cannot call *throttle_check() directly from the notification
handler because we could be handling chip1's notification in chip2. So
initiate an smp_call to execute *throttle_check(). We are irq-disabled
in the notification handler, so use a worker thread to smp_call
throttle_check() on any of the cpu in the chipmask.
Signed-off-by: Shilpasri G Bhat <redacted>
---
Changes from v3:
- Refer to the members of 'struct opal_occ_msg' in the patch.
Replace 'chip_id' with 'omsg.chip'
drivers/cpufreq/powernv-cpufreq.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:11:35
If frequency is throttled due to OCC reset then cpus will be in Psafe
frequency, so restore the frequency on all cpus to policy->cur when
OCCs are active again. And if frequency is throttled due to Pmax
capping then restore the frequency of all the cpus in the chip on
unthrottling.
Signed-off-by: Shilpasri G Bhat <redacted>
---
Changes from v3:
- Refer to the members of 'struct opal_occ_msg' in the patch.
Replace 'reason' with 'omsg.throttle_status'
drivers/cpufreq/powernv-cpufreq.c | 31 +++++++++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
From: Shilpasri G Bhat <hidden> Date: 2015-07-13 14:12:24
On a reset cycle of OCC, although the system retires from safe
frequency state the local pstate is not restored to Pmin or last
requested pstate. Now if the cpufreq governor initiates a pstate
change, the local pstate will be in Psafe and we will be reporting a
false positive when we are not throttled.
So in powernv_cpufreq_throttle_check() remove the condition which
checks if local pstate is less than Pmin while checking for Psafe
frequency. If the cpus are forced to Psafe then PMSR.psafe_mode_active
bit will be set. So, when OCCs become active this bit will be cleared.
Let us just rely on this bit for reporting throttling.
Signed-off-by: Shilpasri G Bhat <redacted>
Reviewed-by: Preeti U Murthy <redacted>
---
No changes from v3
drivers/cpufreq/powernv-cpufreq.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
@@ -335,14 +334,9 @@ static void powernv_cpufreq_throttle_check(void *data)chips[i].id,pmsr_pmax);}-/*-*CheckforPsafebyreadingLocalPstate-*orcheckifPsafe_mode_activeissetinPMSR.-*/+/* Check if Psafe_mode_active is set in PMSR. */next:-pmsr_lp=(s8)PMSR_LP(pmsr);-if((pmsr_lp<powernv_pstate_info.min)||-(pmsr&PMSR_PSAFE_ENABLE)){+if(pmsr&PMSR_PSAFE_ENABLE){throttled=true;pr_info("Pstate set to safe frequency\n");}
You need to ensure the of the members of struct opal_occ_msg are in the
correct byte order when copying them over.
Have you tested this code with in a little endian configuration?
Do the messages you're sending make sense for a system that has a BMC
instead of a FSP?
Cheers,
Joel
You need to ensure the of the members of struct opal_occ_msg are in the
correct byte order when copying them over.
Have you tested this code with in a little endian configuration?
Ah yes this wont work in LE.
I tested the below diff in both BE/LE configuration on Power8 box which has FSP.
- memcpy(&omsg, msg->params, sizeof(omsg));
+ omsg.type = be64_to_cpu(msg->params[0]);
+ omsg.chip = be64_to_cpu(msg->params[1]);
+ omsg.throttle_status = be64_to_cpu(msg->params[2]);
Do the messages you're sending make sense for a system that has a BMC
instead of a FSP?
For a system with BMC, only OCC_THROTTLE will be received by the host. The
remaining two (OCC_RESET and OCC_LOAD) are sent only in FSP based systems.
OCC_THROTTLE is sent by opal which polls on the throttle_status byte in the
OPAL-OCC shared memory region.
This patchset intends to add frequency throttle reporting mechanism
to powernv-cpufreq driver when OCC throttles the frequency. OCC is an
On-Chip-Controller which takes care of the power and thermal safety of
the chip. The CPU frequency can be throttled during an OCC reset or
when OCC tries to limit the max allowed frequency. The patchset will
report such conditions so as to keep the user informed about reason
for the drop in performance of workloads when frequency is throttled.
Changes from v3:
- Rebased on top of 4.2-rc1
- Minor changes in patch 2,3,4,6 this does not change the
functionality of the code
- 594fcb9ec9e powerpc/powernv: Expose OPAL APIs required by PRD
interface , this patch fixes the build error due to which this
series was initially dropped
ERROR: ".opal_message_notifier_register"
drivers/cpufreq/powernv-cpufreq.ko] undefined!
I have already Acked v3 of this and that applies to this one as well..
--
viresh