linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Giovanni Gherdovich <ggherdovich@suse.cz>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@suse.de>,
	Len Brown <lenb@kernel.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	x86@kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Mel Gorman <mgorman@techsingularity.net>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Juri Lelli <juri.lelli@redhat.com>, Paul Turner <pjt@google.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Quentin Perret <qperret@qperret.net>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Doug Smythies <dsmythies@telus.net>
Subject: Re: [PATCH v4 2/6] x86,sched: Add support for frequency invariance on SKYLAKE_X
Date: Wed, 18 Dec 2019 21:06:24 +0100	[thread overview]
Message-ID: <20191218200624.GI11457@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20191113124654.18122-3-ggherdovich@suse.cz>

On Wed, Nov 13, 2019 at 01:46:50PM +0100, Giovanni Gherdovich wrote:
> The scheduler needs the ratio freq_curr/freq_max for frequency-invariant
> accounting. On SKYLAKE_X CPUs set freq_max to the highest frequency that can
> be sustained by a group of at least 4 cores.
> 
> From the changelog of commit 31e07522be56 ("tools/power turbostat: fix
> decoding for GLM, DNV, SKX turbo-ratio limits"):
> 
> >   Newer processors do not hard-code the the number of cpus in each bin
> >   to {1, 2, 3, 4, 5, 6, 7, 8}  Rather, they can specify any number
> >   of CPUS in each of the 8 bins:
> >
> >   eg.
> >
> >   ...
> >   37 * 100.0 = 3600.0 MHz max turbo 4 active cores
> >   38 * 100.0 = 3700.0 MHz max turbo 3 active cores
> >   39 * 100.0 = 3800.0 MHz max turbo 2 active cores
> >   39 * 100.0 = 3900.0 MHz max turbo 1 active cores
> >
> >   could now look something like this:
> >
> >   ...
> >   37 * 100.0 = 3600.0 MHz max turbo 16 active cores
> >   38 * 100.0 = 3700.0 MHz max turbo 8 active cores
> >   39 * 100.0 = 3800.0 MHz max turbo 4 active cores
> >   39 * 100.0 = 3900.0 MHz max turbo 2 active cores
> 
> This encoding of turbo levels applies to both SKYLAKE_X and GOLDMONT/GOLDMONT_D,
> but we treat these two classes in separate commits because their freq_max
> values need to be different. For SKX we prefer a lower freq_max in the ratio
> freq_curr/freq_max, allowing load and utilization to overshoot and the
> schedutil governor to be more performance-oriented. Models from the Atom
> series (such as GOLDMONT*) are handled in a forthcoming commit as they have to
> favor power-efficiency over performance.

Can we at least use a single function to decode both? A little like the
below. I'm not married to the naming, but I think it is a little silly
to have 2 different functions to decode the exact same MSRs.

(one could even go as far as to make a boot param to override the {1,4}
default core count for these things)

---

Index: linux-2.6/arch/x86/kernel/smpboot.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/smpboot.c
+++ linux-2.6/arch/x86/kernel/smpboot.c
@@ -1863,27 +1863,6 @@ static const struct x86_cpu_id has_glm_t
 	{}
 };

-static bool glm_set_cpu_max_freq(u64 *ratio, u64 *turbo_ratio)
-{
-	int err;
-
-	if (!x86_match_cpu(has_glm_turbo_ratio_limits))
-		return false;
-
-	err = rdmsrl_safe(MSR_PLATFORM_INFO, ratio);
-	if (err)
-		return false;
-
-	err = rdmsrl_safe(MSR_TURBO_RATIO_LIMIT, turbo_ratio);
-	if (err)
-		return false;
-
-	*ratio = (*ratio >> 8) & 0xFF;        /* max P state ratio */
-	*turbo_ratio = *turbo_ratio & 0xFF;   /* highest turbo ratio */
-
-	return true;
-}
-
 static int get_knl_turbo_ratio(u64 *turbo_ratio)
 {
 	u64 msr;
@@ -1933,53 +1912,35 @@ static bool knl_set_cpu_max_freq(u64 *ra
 	return true;
 }

-static int get_turbo_ratio_group(u64 *turbo_ratio)
+static bool skx_set_cpu_max_freq(u64 *ratio, u64 *turbo_ratio, int size)
 {
-	u64 ratio, core_counts;
-	u32 group_size = 0;
-	int err, i, found = 0;
+	u64 ratios, counts;
+	u32 group_size;
+	int err, i;

-	err = rdmsrl_safe(MSR_TURBO_RATIO_LIMIT, &ratio);
-	if (err)
-		return err;
-
-	err = rdmsrl_safe(MSR_TURBO_RATIO_LIMIT1, &core_counts);
+	err = rdmsrl_safe(MSR_PLATFORM_INFO, ratio);
 	if (err)
-		return err;
-
-	for (i = 0; i < 64; i += 8) {
-		group_size = (core_counts >> i) & 0xFF;
-		if (group_size >= 4) {
-			*turbo_ratio = (ratio >> i) & 0xFF;
-			found = 1;
-			break;
-		}
-	}
-
-	if (!found)
-		return 1;
-
-	return 0;
-}
-
-static bool skx_set_cpu_max_freq(u64 *ratio, u64 *turbo_ratio)
-{
-	int err;
-
-	if (!x86_match_cpu(has_skx_turbo_ratio_limits))
 		return false;

-	err = rdmsrl_safe(MSR_PLATFORM_INFO, ratio);
+	*ratio = (*ratio >> 8) & 0xFF;                /* max P state ratio */
+
+	err = rdmsrl_safe(MSR_TURBO_RATIO_LIMIT, &ratios);
 	if (err)
 		return false;

-	err = get_turbo_ratio_group(turbo_ratio);  /* 4C (circa) turbo ratio */
+	err = rdmsrl_safe(MSR_TURBO_RATIO_LIMIT1, &counts);
 	if (err)
 		return false;

-	*ratio = (*ratio >> 8) & 0xFF;                /* max P state ratio */
+	for (i = 0; i < 64; i += 8) {
+		group_size = (counts >> i) & 0xFF;
+		if (group_size >= size) {
+			*turbo_ratio = (ratios >> i) & 0xFF;
+			return true;
+		}
+	}

-	return true;
+	return false;
 }

 static bool core_set_cpu_max_freq(u64 *ratio, u64 *turbo_ratio)
@@ -2010,13 +1971,15 @@ static void intel_set_cpu_max_freq(void)
 	if (slv_set_cpu_max_freq(&ratio, &turbo_ratio))
 		goto set_value;

-	if (glm_set_cpu_max_freq(&ratio, &turbo_ratio))
+	if (x86_match_cpu(has_glm_turbo_ratio_limits) &&
+	    skx_set_cpu_max_freq(&ratio, &turbo_ratio, 1))
 		goto set_value;

 	if (knl_set_cpu_max_freq(&ratio, &turbo_ratio))
 		goto set_value;

-	if (skx_set_cpu_max_freq(&ratio, &turbo_ratio))
+	if (x86_match_cpu(has_skx_turbo_ratio_limits) &&
+	    skx_set_cpu_max_freq(&ratio, &turbo_ratio, 4))
 		goto set_value;

 	core_set_cpu_max_freq(&ratio, &turbo_ratio);


  reply	other threads:[~2019-12-18 20:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-13 12:46 [PATCH v4 0/6] Add support for frequency invariance for (some) x86 Giovanni Gherdovich
2019-11-13 12:46 ` [PATCH v4 1/6] x86,sched: Add support for frequency invariance Giovanni Gherdovich
2019-11-24  7:49   ` Doug Smythies
2019-11-25  8:16     ` Doug Smythies
2019-11-25  9:16     ` Mel Gorman
2019-11-25 16:06     ` Giovanni Gherdovich
2019-11-26  5:59       ` Doug Smythies
2019-11-26 15:20         ` Giovanni Gherdovich
2019-11-27  7:32           ` Doug Smythies
2019-11-28 22:48             ` Doug Smythies
2019-12-19 10:48               ` Qais Yousef
2019-12-23  7:47                 ` Doug Smythies
2019-12-23 14:07                   ` Qais Yousef
2019-12-23 14:40                     ` Qais Yousef
2019-12-23 16:34                       ` Doug Smythies
2019-12-23 19:10                         ` Qais Yousef
2019-12-24  1:16                           ` Doug Smythies
2019-12-24 11:08                             ` Qais Yousef
2019-12-02 16:34   ` Ionela Voinescu
2019-12-06 11:57     ` Giovanni Gherdovich
2019-12-18 19:34       ` Peter Zijlstra
2019-12-19 20:27         ` Giovanni Gherdovich
2019-11-13 12:46 ` [PATCH v4 2/6] x86,sched: Add support for frequency invariance on SKYLAKE_X Giovanni Gherdovich
2019-12-18 20:06   ` Peter Zijlstra [this message]
2019-12-19 20:29     ` Giovanni Gherdovich
2019-11-13 12:46 ` [PATCH v4 3/6] x86,sched: Add support for frequency invariance on XEON_PHI_KNL/KNM Giovanni Gherdovich
2019-12-18 20:22   ` Peter Zijlstra
2019-12-19 20:32     ` Giovanni Gherdovich
2019-11-13 12:46 ` [PATCH v4 4/6] x86,sched: Add support for frequency invariance on ATOM_GOLDMONT* Giovanni Gherdovich
2019-11-13 12:46 ` [PATCH v4 5/6] x86,sched: Add support for frequency invariance on ATOM Giovanni Gherdovich
2019-11-13 16:50   ` Srinivas Pandruvada
2019-11-15 10:34     ` Giovanni Gherdovich
2019-11-13 12:46 ` [PATCH v4 6/6] x86: intel_pstate: handle runtime turbo disablement/enablement in freq. invariance Giovanni Gherdovich
2019-12-18 20:37 ` [PATCH v4 0/6] Add support for frequency invariance for (some) x86 Peter Zijlstra
2019-12-19 20:33   ` Giovanni Gherdovich

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=20191218200624.GI11457@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bp@suse.de \
    --cc=dietmar.eggemann@arm.com \
    --cc=dsmythies@telus.net \
    --cc=ggherdovich@suse.cz \
    --cc=juri.lelli@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=pjt@google.com \
    --cc=qperret@qperret.net \
    --cc=rjw@rjwysocki.net \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).