From: "Gautham R. Shenoy" <gautham.shenoy@amd.com>
To: Mario Limonciello <superm1@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>, Perry Yuan <perry.yuan@amd.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, "Rafael J . Wysocki" <rafael@kernel.org>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@vger.kernel.org>,
"open list:ACPI" <linux-acpi@vger.kernel.org>,
"open list:CPU FREQUENCY SCALING FRAMEWORK"
<linux-pm@vger.kernel.org>,
Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH 5/8] x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()
Date: Tue, 27 Aug 2024 21:13:59 +0530 [thread overview]
Message-ID: <Zs30P9EThSvLLZg5@BLRRASHENOY1.amd.com> (raw)
In-Reply-To: <20240826211358.2694603-6-superm1@kernel.org>
On Mon, Aug 26, 2024 at 04:13:55PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello <mario.limonciello@amd.com>
>
> AMD systems that support preferred cores will use "166" as their
> numerator for max frequency calculations instead of "255".
>
> Add a function for detecting preferred cores by looking at the
> highest perf value on all cores.
>
> If preferred cores are enabled return 166 and if disabled the
> value in the highest perf register. As the function will be called
> multiple times, cache the values for the boost numerator and if
> preferred cores will be enabled in global variables.
>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
[..snip..]
> /**
> * amd_get_boost_ratio_numerator: Get the numerator to use for boost ratio calculation
> * @cpu: CPU to get numerator for.
> @@ -162,20 +232,19 @@ EXPORT_SYMBOL_GPL(amd_get_highest_perf);
> */
> int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator)
> {
> - struct cpuinfo_x86 *c = &boot_cpu_data;
> + bool prefcore;
> + int ret;
>
> - if (c->x86 == 0x17 && ((c->x86_model >= 0x30 && c->x86_model < 0x40) ||
> - (c->x86_model >= 0x70 && c->x86_model < 0x80))) {
> - *numerator = 166;
> - return 0;
> - }
> + ret = amd_detect_prefcore(&prefcore);
> + if (ret)
> + return ret;
>
> - if (c->x86 == 0x19 && ((c->x86_model >= 0x20 && c->x86_model < 0x30) ||
> - (c->x86_model >= 0x40 && c->x86_model < 0x70))) {
> - *numerator = 166;
> + /* without preferred cores, return the highest perf register value */
> + if (!prefcore) {
> + *numerator = boost_numerator;
> return 0;
> }
> - *numerator = 255;
> + *numerator = CPPC_HIGHEST_PERF_PREFCORE;
Interesting. So even when the user boots a system that supports
preferred-cores with "amd_preferred=disable",
amd_get_boost_ratio_numerator() will return CPPC_HIGHEST_PERF_PREFCORE
as the call prefcore == true here.
I suppose that is as intended, since even though the user may not want
to use the preferred core logic for task-scheduling/load-balancing,
the numerator for the boost-ratio is purely dependent on the h/w
capability.
Is this understanding correct? If so, can this be included as a
comment in the code ?
The rest of the patch looks good to me.
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
--
Thanks and Regards
gautham.
>
> return 0;
> }
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index f470b5700db58..ec32c830abc1d 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -807,32 +807,18 @@ static DECLARE_WORK(sched_prefcore_work, amd_pstste_sched_prefcore_workfn);
>
> static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)
> {
> - int ret, prio;
> - u32 highest_perf;
> -
> - ret = amd_get_highest_perf(cpudata->cpu, &highest_perf);
> - if (ret)
> + /* user disabled or not detected */
> + if (!amd_pstate_prefcore)
> return;
>
> cpudata->hw_prefcore = true;
> - /* check if CPPC preferred core feature is enabled*/
> - if (highest_perf < CPPC_MAX_PERF)
> - prio = (int)highest_perf;
> - else {
> - pr_debug("AMD CPPC preferred core is unsupported!\n");
> - cpudata->hw_prefcore = false;
> - return;
> - }
> -
> - if (!amd_pstate_prefcore)
> - return;
>
> /*
> * The priorities can be set regardless of whether or not
> * sched_set_itmt_support(true) has been called and it is valid to
> * update them at any time after it has been called.
> */
> - sched_set_itmt_core_prio(prio, cpudata->cpu);
> + sched_set_itmt_core_prio((int)READ_ONCE(cpudata->highest_perf), cpudata->cpu);
>
> schedule_work(&sched_prefcore_work);
> }
> @@ -998,12 +984,12 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
>
> cpudata->cpu = policy->cpu;
>
> - amd_pstate_init_prefcore(cpudata);
> -
> ret = amd_pstate_init_perf(cpudata);
> if (ret)
> goto free_cpudata1;
>
> + amd_pstate_init_prefcore(cpudata);
> +
> ret = amd_pstate_init_freq(cpudata);
> if (ret)
> goto free_cpudata1;
> @@ -1453,12 +1439,12 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
> cpudata->cpu = policy->cpu;
> cpudata->epp_policy = 0;
>
> - amd_pstate_init_prefcore(cpudata);
> -
> ret = amd_pstate_init_perf(cpudata);
> if (ret)
> goto free_cpudata1;
>
> + amd_pstate_init_prefcore(cpudata);
> +
> ret = amd_pstate_init_freq(cpudata);
> if (ret)
> goto free_cpudata1;
> @@ -1903,6 +1889,12 @@ static int __init amd_pstate_init(void)
> static_call_update(amd_pstate_update_perf, cppc_update_perf);
> }
>
> + if (amd_pstate_prefcore) {
> + ret = amd_detect_prefcore(&amd_pstate_prefcore);
> + if (ret)
> + return ret;
> + }
> +
> /* enable amd pstate feature */
> ret = amd_pstate_enable(true);
> if (ret) {
> diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
> index 2246ce0630362..1d79320a23490 100644
> --- a/include/acpi/cppc_acpi.h
> +++ b/include/acpi/cppc_acpi.h
> @@ -137,10 +137,12 @@ struct cppc_cpudata {
> };
>
> #ifdef CONFIG_CPU_SUP_AMD
> +extern int amd_detect_prefcore(bool *detected);
> extern int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf);
> extern int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator);
> #else /* !CONFIG_CPU_SUP_AMD */
> static inline int amd_get_highest_perf(unsigned int cpu, u32 *highest_perf) { return -ENODEV; }
> +static inline int amd_detect_prefcore(bool *detected) { return -ENODEV; }
> static inline int amd_get_boost_ratio_numerator(unsigned int cpu, u64 *numerator) { return -ENODEV; }
> #endif /* !CONFIG_CPU_SUP_AMD */
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2024-08-27 15:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 21:13 [PATCH 0/8] Adjustments for preferred core detection Mario Limonciello
2024-08-26 21:13 ` [PATCH 1/8] x86/amd: Move amd_get_highest_perf() from amd.c to cppc.c Mario Limonciello
2024-08-27 6:29 ` Yuan, Perry
2024-08-27 14:08 ` Gautham R. Shenoy
2024-08-28 5:23 ` kernel test robot
2024-08-26 21:13 ` [PATCH 2/8] x86/amd: Rename amd_get_highest_perf() to amd_get_boost_ratio_numerator() Mario Limonciello
2024-08-27 14:42 ` Gautham R. Shenoy
2024-08-27 18:18 ` Mario Limonciello
2024-08-28 9:09 ` kernel test robot
2024-08-26 21:13 ` [PATCH 3/8] ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn Mario Limonciello
2024-08-27 6:37 ` Yuan, Perry
2024-08-27 14:50 ` Gautham R. Shenoy
2024-08-27 18:48 ` Mario Limonciello
2024-08-26 21:13 ` [PATCH 4/8] x86/amd: Move amd_get_highest_perf() out of amd-pstate Mario Limonciello
2024-08-27 6:46 ` Yuan, Perry
2024-08-27 15:01 ` Gautham R. Shenoy
2024-08-26 21:13 ` [PATCH 5/8] x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator() Mario Limonciello
2024-08-27 15:43 ` Gautham R. Shenoy [this message]
2024-08-27 19:00 ` Mario Limonciello
2024-08-26 21:13 ` [PATCH 6/8] cpufreq: amd-pstate: Merge amd_pstate_highest_perf_set() into amd_get_boost_ratio_numerator() Mario Limonciello
2024-08-27 16:52 ` Gautham R. Shenoy
2024-08-27 18:36 ` Mario Limonciello
2024-08-28 5:59 ` Gautham R. Shenoy
2024-08-27 21:31 ` kernel test robot
2024-08-26 21:13 ` [PATCH 7/8] cpufreq: amd-pstate: Optimize amd_pstate_update_limits() Mario Limonciello
2024-08-27 6:48 ` Yuan, Perry
2024-08-27 16:57 ` Gautham R. Shenoy
2024-08-27 19:02 ` Mario Limonciello
2024-08-26 21:13 ` [PATCH 8/8] cpufreq: amd-pstate: Drop some uses of cpudata->hw_prefcore Mario Limonciello
2024-08-27 6:53 ` Yuan, Perry
2024-08-27 17:03 ` Gautham R. Shenoy
2024-08-27 19:16 ` Mario Limonciello
2024-08-28 5:08 ` Gautham R. Shenoy
2024-08-28 6:20 ` Andrea Righi
2024-08-28 14:57 ` Gautham R. Shenoy
2024-08-29 12:52 ` Andrea Righi
2024-08-29 13:01 ` Mario Limonciello
2024-08-29 15:16 ` Andrea Righi
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=Zs30P9EThSvLLZg5@BLRRASHENOY1.amd.com \
--to=gautham.shenoy@amd.com \
--cc=bp@alien8.de \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=perry.yuan@amd.com \
--cc=rafael@kernel.org \
--cc=superm1@kernel.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 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.