All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gautham R. Shenoy" <gautham.shenoy@amd.com>
To: Andrea Righi <andrea.righi@linux.dev>
Cc: Mario Limonciello <mario.limonciello@amd.com>,
	Mario Limonciello <superm1@kernel.org>,
	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>,
	changwoo@igalia.com, David Vernet <void@manifault.com>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 8/8] cpufreq: amd-pstate: Drop some uses of cpudata->hw_prefcore
Date: Wed, 28 Aug 2024 20:27:44 +0530	[thread overview]
Message-ID: <Zs866Myvbs0ByoAK@BLRRASHENOY1.amd.com> (raw)
In-Reply-To: <Zs7Bwh6T3HCGlR9C@gpd3>

Hello Andrea,

On Wed, Aug 28, 2024 at 08:20:50AM +0200, Andrea Righi wrote:
> On Wed, Aug 28, 2024 at 10:38:45AM +0530, Gautham R. Shenoy wrote:
> ...
> > > I had thought this was a malfunction in the behavior that it reflected the
> > > current status, not the hardware /capability/.
> > > 
> > > Which one makes more sense for userspace?  In my mind the most likely
> > > consumer of this information would be something a sched_ext based userspace
> > > scheduler.  They would need to know whether the scheduler was using
> > > preferred cores; not whether the hardware supported it.
> > 
> > The commandline parameter currently impacts only the fair sched-class
> > tasks since the preference information gets used only during
> > load-balancing.
> > 
> > IMO, the same should continue with sched-ext, i.e. if the user has
> > explicitly disabled prefcore support via commandline, the no sched-ext
> > scheduler should use the preference information to make task placement
> > decisions. However, I would like to see what the sched-ext folks have
> > to say. Adding some of them to the Cc list.
> 
> IMHO it makes more sense to reflect the real state of prefcore support
> from a "system" perspective, more than a "hardware" perspective, so if
> it's disabled via boot command line it should show disabled.
> 
> From a user-space scheduler perspective we should be fine either way, as
> long as the ABI is clearly documented, since we also have access to
> /proc/cmdline and we would be able to figure out if the user has
> disabled it via cmdline (however, the preference is still to report the
> actual system status).

Thank you for confirming this.

> 
> Question: having prefcore enabled affects also the value of
> scaling_max_freq? Like an `lscpu -e`, for example, would show a higher
> max frequency for the specific preferred cores? (this is another useful
> information from a sched_ext scheduler perspective).

Since the scaling_max_freq is computed based on the boost-numerator,
at least from this patchset, the numerator would be the same across
all kinds of cores, and thus the scaling_max_freq reported will be the
same across all the cores.

> 
> Thanks,
> -Andrea

--
Thanks and Regards
gautham.

  reply	other threads:[~2024-08-28 14:57 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
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 [this message]
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=Zs866Myvbs0ByoAK@BLRRASHENOY1.amd.com \
    --to=gautham.shenoy@amd.com \
    --cc=andrea.righi@linux.dev \
    --cc=bp@alien8.de \
    --cc=changwoo@igalia.com \
    --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=tj@kernel.org \
    --cc=void@manifault.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.