All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Rebe <rene@exactcode.com>
To: Meng Li <li.meng@amd.com>
Cc: Huang Rui <ray.huang@amd.com>, <linux-pm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	<linux-acpi@vger.kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	<linux-kselftest@vger.kernel.org>,
	"Nathan Fontenot" <nathan.fontenot@amd.com>,
	Deepak Sharma <deepak.sharma@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Shimmer Huang <shimmer.huang@amd.com>,
	"Perry Yuan" <Perry.Yuan@amd.com>,
	Xiaojian Du <Xiaojian.Du@amd.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Borislav Petkov <bp@alien8.de>, Meng Li <li.meng@amd.com>,
	Wyes Karny <wyes.karny@amd.com>
Subject: Re: [PATCH V4 3/7] cpufreq: amd-pstate: Enable AMD Pstate Preferred Core Supporting.
Date: Tue, 29 Aug 2023 11:35:19 +0200 (CEST)	[thread overview]
Message-ID: <20230829.113519.1499398743089914237.rene@exactcode.com> (raw)

Dear Meng Li and team,

thank you so much for working on finally bringing AMD preferred core
scheduling to mainline Linux!

> The initial core rankings are set up by AMD Pstate when the
> system boots.

I tested this patch on our Ryzen 7950x and 5950x systems and could
unfortunatlely not find any performance differences. I therefore took
a closer look and as far as I can tell the conditional for the initial
preferred performance priorities appears to be reversed. I marked them
down below. I also attached a patch for the fix. With that fixed I can
measure a 0.7% improvement compiling Firefox on 7950x. I wonder
slightly how this ever past testing before, ...

I think it would be a good idea to always expose the hw perf values in
sysfs to help users debugging hardware issues or BIOS settings even
with percore not enabled and therefore not using the unused 166 or 255
values anyway.

With that fixed, however, Linux is still not always scheduling to
preferred cores, but that appears to be an independant limitation of
the current linux scheduler not strictly using the priority for
scheduling, yet. With manual taskset guidance I could further improve
the Firefox build time by some more seconds to over 1% overall
performance improvement, if the linux scheudler would more reliably
schedule minute long running rust lto link tasks to the preferred
cores and not some mediocre ones.


> -	highest_perf = amd_get_highest_perf();
> -	if (highest_perf > AMD_CPPC_HIGHEST_PERF(cap1))
> -		highest_perf = AMD_CPPC_HIGHEST_PERF(cap1);
> -
> -	WRITE_ONCE(cpudata->highest_perf, highest_perf);
> +	if (prefcore)
> +		WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
> +	else
> +		WRITE_ONCE(cpudata->highest_perf, AMD_CPPC_HIGHEST_PERF(cap1));

Conditional reversed, assigns THRESHOLD if enabled!

>  	WRITE_ONCE(cpudata->nominal_perf, AMD_CPPC_NOMINAL_PERF(cap1));
>  	WRITE_ONCE(cpudata->lowest_nonlinear_perf, AMD_CPPC_LOWNONLIN_PERF(cap1));
> @@ -318,17 +322,15 @@ static int pstate_init_perf(struct amd_cpudata *cpudata)
>  static int cppc_init_perf(struct amd_cpudata *cpudata)
>  {
>  	struct cppc_perf_caps cppc_perf;
> -	u32 highest_perf;
>  
>  	int ret = cppc_get_perf_caps(cpudata->cpu, &cppc_perf);
>  	if (ret)
>  		return ret;
>  
> -	highest_perf = amd_get_highest_perf();
> -	if (highest_perf > cppc_perf.highest_perf)
> -		highest_perf = cppc_perf.highest_perf;
> -
> -	WRITE_ONCE(cpudata->highest_perf, highest_perf);
> +	if (prefcore)
> +		WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
> +	else
> +		WRITE_ONCE(cpudata->highest_perf, cppc_perf.highest_perf);

Same here. Not using highest_perf if enabled, ...

Signed-off-by: René Rebe <rene@exactcode.de>

--- linux-6.4/drivers/cpufreq/amd-pstate.c.vanilla	2023-08-25 22:34:25.254995690 +0200
+++ linux-6.4/drivers/cpufreq/amd-pstate.c	2023-08-25 22:35:49.194991446 +0200
@@ -282,9 +282,9 @@
 	 * the default max perf.
 	 */
 	if (prefcore)
-		WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
-	else
 		WRITE_ONCE(cpudata->highest_perf, AMD_CPPC_HIGHEST_PERF(cap1));
+	else
+		WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
 
 	WRITE_ONCE(cpudata->nominal_perf, AMD_CPPC_NOMINAL_PERF(cap1));
 	WRITE_ONCE(cpudata->lowest_nonlinear_perf, AMD_CPPC_LOWNONLIN_PERF(cap1));
@@ -303,9 +303,9 @@
 		return ret;
 
 	if (prefcore)
-		WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
-	else
 		WRITE_ONCE(cpudata->highest_perf, cppc_perf.highest_perf);
+	else
+		WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
 
 	WRITE_ONCE(cpudata->nominal_perf, cppc_perf.nominal_perf);
 	WRITE_ONCE(cpudata->lowest_nonlinear_perf,


-- 
  René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
  https://exactcode.com | https://t2sde.org | https://rene.rebe.de

             reply	other threads:[~2023-08-29 10:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29  9:35 Rene Rebe [this message]
2023-08-31  9:02 ` [PATCH V4 3/7] cpufreq: amd-pstate: Enable AMD Pstate Preferred Core Supporting Meng, Li (Jassmine)
  -- strict thread matches above, loose matches on Subject: below --
2023-08-29  6:43 [PATCH V4 0/7] AMD Pstate Preferred Core Meng Li
2023-08-29  6:43 ` [PATCH V4 3/7] cpufreq: amd-pstate: Enable AMD Pstate Preferred Core Supporting Meng Li
2023-08-29  8:01   ` Huang Rui
2023-08-31  1:42     ` Meng, Li (Jassmine)
2023-08-29 14:52   ` kernel test robot

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=20230829.113519.1499398743089914237.rene@exactcode.com \
    --to=rene@exactcode.com \
    --cc=Perry.Yuan@amd.com \
    --cc=Xiaojian.Du@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=bp@alien8.de \
    --cc=deepak.sharma@amd.com \
    --cc=li.meng@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=nathan.fontenot@amd.com \
    --cc=ray.huang@amd.com \
    --cc=shimmer.huang@amd.com \
    --cc=skhan@linuxfoundation.org \
    --cc=viresh.kumar@linaro.org \
    --cc=wyes.karny@amd.com \
    --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 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.