From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>,
linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v3 4/6] cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE
Date: Tue, 05 May 2015 09:30:50 +0530 [thread overview]
Message-ID: <55484072.5060400@linux.vnet.ibm.com> (raw)
In-Reply-To: <1430729652-14813-5-git-send-email-shilpa.bhat@linux.vnet.ibm.com>
Hi Shilpa,
On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
> 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.
I see that the first patch takes care of reporting *per-chip* throttling
for pmax capping condition. But where are we taking care of reporting
"pstate set to safe" and "freq control disabled" scenarios per-chip ?
>
> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index 9268424..9618813 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -50,6 +50,8 @@ static bool rebooting, throttled, occ_reset;
> static struct chip {
> unsigned int id;
> bool throttled;
> + cpumask_t mask;
> + struct work_struct throttle;
> } *chips;
>
> static int nr_chips;
> @@ -310,8 +312,9 @@ static inline unsigned int get_nominal_index(void)
> return powernv_pstate_info.max - powernv_pstate_info.nominal;
> }
>
> -static void powernv_cpufreq_throttle_check(unsigned int cpu)
> +static void powernv_cpufreq_throttle_check(void *data)
> {
> + unsigned int cpu = smp_processor_id();
> unsigned long pmsr;
> int pmsr_pmax, pmsr_lp, i;
>
> @@ -373,7 +376,7 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
> return 0;
>
> if (!throttled)
> - powernv_cpufreq_throttle_check(smp_processor_id());
> + powernv_cpufreq_throttle_check(NULL);
>
> freq_data.pstate_id = powernv_freqs[new_index].driver_data;
>
> @@ -418,6 +421,14 @@ static struct notifier_block powernv_cpufreq_reboot_nb = {
> .notifier_call = powernv_cpufreq_reboot_notifier,
> };
>
> +void powernv_cpufreq_work_fn(struct work_struct *work)
> +{
> + struct chip *chip = container_of(work, struct chip, throttle);
> +
> + smp_call_function_any(&chip->mask,
> + powernv_cpufreq_throttle_check, NULL, 0);
> +}
> +
> static char throttle_reason[][30] = {
> "No throttling",
> "Power Cap",
> @@ -433,6 +444,7 @@ static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> struct opal_msg *occ_msg = msg;
> uint64_t token;
> uint64_t chip_id, reason;
> + int i;
>
> if (msg_type != OPAL_MSG_OCC)
> return 0;
> @@ -466,6 +478,10 @@ static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> occ_reset = false;
> throttled = false;
> pr_info("OCC: Active\n");
> +
> + for (i = 0; i < nr_chips; i++)
> + schedule_work(&chips[i].throttle);
> +
> return 0;
> }
>
> @@ -476,6 +492,12 @@ static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> else if (!reason)
> pr_info("OCC: Chip %u %s\n", (unsigned int)chip_id,
> throttle_reason[reason]);
> + else
> + return 0;
Why the else section ? The code can never reach here, can it ?
> +
> + for (i = 0; i < nr_chips; i++)
> + if (chips[i].id == chip_id)
> + schedule_work(&chips[i].throttle);
> }
Should we not do this only when we get unthrottled so as to cross verify
if it is indeed the case ? In case of throttling notification, opal's
verdict is final and there is no need to cross verify right ?
Perhaps the one thing that needs to be taken care in addition to
reporting throttling is setting the chip's throttled parameter to true.
This should do right ? I don't see the need to call throttle_check() here.
Regards
Preeti U Murthy
> return 0;
> }
> @@ -527,6 +549,8 @@ static int init_chip_info(void)
> for (i = 0; i < nr_chips; i++) {
> chips[i].id = chip[i];
> chips[i].throttled = false;
> + cpumask_copy(&chips[i].mask, cpumask_of_node(chip[i]));
> + INIT_WORK(&chips[i].throttle, powernv_cpufreq_work_fn);
> }
>
> return 0;
>
WARNING: multiple messages have this Message-ID (diff)
From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>,
linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Cc: viresh.kumar@linaro.org, rjw@rjwysocki.net, linux-pm@vger.kernel.org
Subject: Re: [PATCH v3 4/6] cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE
Date: Tue, 05 May 2015 09:30:50 +0530 [thread overview]
Message-ID: <55484072.5060400@linux.vnet.ibm.com> (raw)
In-Reply-To: <1430729652-14813-5-git-send-email-shilpa.bhat@linux.vnet.ibm.com>
Hi Shilpa,
On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
> 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.
I see that the first patch takes care of reporting *per-chip* throttling
for pmax capping condition. But where are we taking care of reporting
"pstate set to safe" and "freq control disabled" scenarios per-chip ?
>
> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index 9268424..9618813 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -50,6 +50,8 @@ static bool rebooting, throttled, occ_reset;
> static struct chip {
> unsigned int id;
> bool throttled;
> + cpumask_t mask;
> + struct work_struct throttle;
> } *chips;
>
> static int nr_chips;
> @@ -310,8 +312,9 @@ static inline unsigned int get_nominal_index(void)
> return powernv_pstate_info.max - powernv_pstate_info.nominal;
> }
>
> -static void powernv_cpufreq_throttle_check(unsigned int cpu)
> +static void powernv_cpufreq_throttle_check(void *data)
> {
> + unsigned int cpu = smp_processor_id();
> unsigned long pmsr;
> int pmsr_pmax, pmsr_lp, i;
>
> @@ -373,7 +376,7 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
> return 0;
>
> if (!throttled)
> - powernv_cpufreq_throttle_check(smp_processor_id());
> + powernv_cpufreq_throttle_check(NULL);
>
> freq_data.pstate_id = powernv_freqs[new_index].driver_data;
>
> @@ -418,6 +421,14 @@ static struct notifier_block powernv_cpufreq_reboot_nb = {
> .notifier_call = powernv_cpufreq_reboot_notifier,
> };
>
> +void powernv_cpufreq_work_fn(struct work_struct *work)
> +{
> + struct chip *chip = container_of(work, struct chip, throttle);
> +
> + smp_call_function_any(&chip->mask,
> + powernv_cpufreq_throttle_check, NULL, 0);
> +}
> +
> static char throttle_reason[][30] = {
> "No throttling",
> "Power Cap",
> @@ -433,6 +444,7 @@ static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> struct opal_msg *occ_msg = msg;
> uint64_t token;
> uint64_t chip_id, reason;
> + int i;
>
> if (msg_type != OPAL_MSG_OCC)
> return 0;
> @@ -466,6 +478,10 @@ static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> occ_reset = false;
> throttled = false;
> pr_info("OCC: Active\n");
> +
> + for (i = 0; i < nr_chips; i++)
> + schedule_work(&chips[i].throttle);
> +
> return 0;
> }
>
> @@ -476,6 +492,12 @@ static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
> else if (!reason)
> pr_info("OCC: Chip %u %s\n", (unsigned int)chip_id,
> throttle_reason[reason]);
> + else
> + return 0;
Why the else section ? The code can never reach here, can it ?
> +
> + for (i = 0; i < nr_chips; i++)
> + if (chips[i].id == chip_id)
> + schedule_work(&chips[i].throttle);
> }
Should we not do this only when we get unthrottled so as to cross verify
if it is indeed the case ? In case of throttling notification, opal's
verdict is final and there is no need to cross verify right ?
Perhaps the one thing that needs to be taken care in addition to
reporting throttling is setting the chip's throttled parameter to true.
This should do right ? I don't see the need to call throttle_check() here.
Regards
Preeti U Murthy
> return 0;
> }
> @@ -527,6 +549,8 @@ static int init_chip_info(void)
> for (i = 0; i < nr_chips; i++) {
> chips[i].id = chip[i];
> chips[i].throttled = false;
> + cpumask_copy(&chips[i].mask, cpumask_of_node(chip[i]));
> + INIT_WORK(&chips[i].throttle, powernv_cpufreq_work_fn);
> }
>
> return 0;
>
next prev parent reply other threads:[~2015-05-05 4:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 8:54 [PATCH v3 0/6] powernv: cpufreq: Report frequency throttle by OCC Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-04 8:54 ` [PATCH v3 1/6] cpufreq: poowernv: Handle throttling due to Pmax capping at chip level Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-05 3:51 ` Preeti U Murthy
2015-05-05 3:51 ` Preeti U Murthy
2015-05-05 6:06 ` Shilpasri G Bhat
2015-05-05 6:06 ` Shilpasri G Bhat
2015-05-05 8:38 ` Preeti U Murthy
2015-05-07 10:35 ` Shilpasri G Bhat
2015-05-07 12:15 ` Preeti U Murthy
2015-05-04 8:54 ` [PATCH v3 2/6] powerpc/powernv: Add definition of OPAL_MSG_OCC message type Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-04 8:54 ` [PATCH v3 3/6] cpufreq: powernv: Register for OCC related opal_message notification Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-05 3:42 ` Preeti U Murthy
2015-05-05 3:42 ` Preeti U Murthy
2015-05-04 8:54 ` [PATCH v3 4/6] cpufreq: powernv: Call throttle_check() on receiving OCC_THROTTLE Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-05 4:00 ` Preeti U Murthy [this message]
2015-05-05 4:00 ` Preeti U Murthy
2015-05-05 6:33 ` Shilpasri G Bhat
2015-05-05 6:33 ` Shilpasri G Bhat
2015-05-05 8:41 ` Preeti U Murthy
2015-05-07 12:19 ` Preeti U Murthy
2015-05-07 20:59 ` Rafael J. Wysocki
2015-05-07 20:59 ` Rafael J. Wysocki
2015-05-08 3:46 ` Preeti U Murthy
2015-05-08 3:46 ` Preeti U Murthy
2015-05-08 14:11 ` Rafael J. Wysocki
2015-05-08 14:11 ` Rafael J. Wysocki
2015-05-04 8:54 ` [PATCH v3 5/6] cpufreq: powernv: Report Psafe only if PMSR.psafe_mode_active bit is set Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-05 3:46 ` Preeti U Murthy
2015-05-04 8:54 ` [PATCH v3 6/6] cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling Shilpasri G Bhat
2015-05-04 8:54 ` Shilpasri G Bhat
2015-05-05 9:39 ` Preeti U Murthy
2015-05-05 9:39 ` Preeti U Murthy
2015-05-08 5:12 ` [PATCH v3 0/6] powernv: cpufreq: Report frequency throttle by OCC Viresh Kumar
2015-05-08 5:12 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55484072.5060400@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=rjw@rjwysocki.net \
--cc=shilpa.bhat@linux.vnet.ibm.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.