linux-kernel - Re: [PATCH v3 1/6] cpufreq: poowernv: Handle throttling due to Pmax capping at chip level

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 05 May 2015 09:21:39 +0530
From:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
To:	Shilpasri G Bhat <shilpa.bhat@...ux.vnet.ibm.com>,
	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org
CC:	rjw@...ysocki.net, viresh.kumar@...aro.org,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 1/6] cpufreq: poowernv: Handle throttling due to Pmax
 capping at chip level

Hi Shilpa,

On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
> 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 <shilpa.bhat@...ux.vnet.ibm.com>
> ---
>  drivers/cpufreq/powernv-cpufreq.c | 59 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 55 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index ebef0d8..d0c18c9 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -27,6 +27,7 @@
>  #include <linux/smp.h>
>  #include <linux/of.h>
>  #include <linux/reboot.h>
> +#include <linux/slab.h>
> 
>  #include <asm/cputhreads.h>
>  #include <asm/firmware.h>
> @@ -42,6 +43,13 @@
>  static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
>  static bool rebooting, throttled;
> 
> +static struct chip {
> +	unsigned int id;
> +	bool throttled;
> +} *chips;
> +
> +static int nr_chips;
> +
>  /*
>   * Note: The set of pstates consists of contiguous integers, the
>   * smallest of which is indicated by powernv_pstate_info.min, the
> @@ -301,22 +309,33 @@ static inline unsigned int get_nominal_index(void)
>  static void powernv_cpufreq_throttle_check(unsigned int cpu)
>  {
>  	unsigned long pmsr;
> -	int pmsr_pmax, pmsr_lp;
> +	int pmsr_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)
> +			goto next;
> +		chips[i].throttled = true;
> +		pr_info("CPU %d on Chip %u has Pmax reduced to %d\n", cpu,
> +			chips[i].id, pmsr_pmax);
> +	} else if (chips[i].throttled) {
> +		chips[i].throttled = false;

Is this check on pmax sufficient to indicate that the chip is unthrottled ?

> +		pr_info("CPU %d on Chip %u has Pmax restored to %d\n", cpu,
> +			chips[i].id, pmsr_pmax);
>  	}
> 
>  	/*
>  	 * Check for Psafe by reading LocalPstate
>  	 * or 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)) {
> @@ -414,6 +433,33 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
>  	.attr		= powernv_cpu_freq_attr,

What about the situation where although occ is active, this particular
chip has been throttled and we end up repeatedly reporting "pstate set
to safe" and "frequency control disabled from OS" ? Should we not have a
check on (chips[i].throttled) before reporting an anomaly for these two
scenarios as well just like you have for pmsr_pmax ?

Regards
Preeti U Murthy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/