All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gautham R. Shenoy" <gautham.shenoy@amd.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: Mario Limonciello <superm1@kernel.org>,
	Perry Yuan <perry.yuan@amd.com>,
	Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<linux-kernel@vger.kernel.org>,
	"open list:CPU FREQUENCY SCALING FRAMEWORK"
	<linux-pm@vger.kernel.org>
Subject: Re: [PATCH v2 3/5] cpufreq/amd-pstate: Add support for platform profile class
Date: Mon, 10 Mar 2025 10:39:04 +0530	[thread overview]
Message-ID: <Z85z8MN8ncr2ye4r@BLRRASHENOY1.amd.com> (raw)
In-Reply-To: <f3849033-e883-4296-abb7-eb04e8c2a03c@amd.com>

[...snip...]

On Fri, Mar 07, 2025 at 10:30:25PM -0600, Mario Limonciello wrote:
> On 3/7/2025 10:55, Mario Limonciello wrote:
> > On 3/7/2025 10:22, Gautham R. Shenoy wrote:
> > > > +static int amd_pstate_profile_set(struct device *dev,
> > > > +                  enum platform_profile_option profile)
> > > > +{
> > > > +    struct amd_cpudata *cpudata = dev_get_drvdata(dev);
> > > > +    struct cpufreq_policy *policy __free(put_cpufreq_policy) =
> > > > cpufreq_cpu_get(cpudata->cpu);
> > > > +    int ret;
> > > > +
> > > > +    switch (profile) {
> > > > +    case PLATFORM_PROFILE_LOW_POWER:
> > > > +        if (cpudata->policy != CPUFREQ_POLICY_POWERSAVE)
> > > > +            cpudata->policy = CPUFREQ_POLICY_POWERSAVE;
> > > 
> > > So prior to the patch, cpudata->policy is supposed to mirror
> > > policy->policy.  With this patch, this assumption is no longer
> > > true. So it is possible for the user to again override the choice of
> > > EPP set via platform profile by changing the cpufreq governor ?
> > > 
> > > Is this the expected behaviour?
> > > 
> > > The bigger concern is, if the governor was previously "performance"
> > > and then the platform profile requested "low power", "cat
> > > /sys/devices/system/cpu/cpuX/cpufreq/scaling_governor" would still
> > > show "performance", which is inconsistent with the behaviour.
> > > 
> > > 
> > 
> > This ties back to the previous patches for dynamic EPP.  My expectation
> > was that when dynamic EPP is enabled that users can't manually set the
> > EPP anymore (it will return -EBUSY) and likewise turning on dynamic EPP
> > should keep the governor as powersave.
> > 
> > I'll double check all those are properly enforced; but that's at least
> > the intent.
> 
> FWIW - I double checked and confirmed that this is working as intended.
> * I couldn't change from powersave to performance when dynamic_epp was
> enabled (-EBUSY)
> * I couldn't change energy_performance_preference when dynamic_epp was
> enabled (-EBUSY)

Thanks for double checking this. 


> 
> > 
> > IMO this "should" all work because turning on Dynamic EPP sysfs file
> > forces the driver to go through a state transition that it will tear
> > everything down and back up.  The policy will come back up in
> > "powersave" even if it was previously in "performance" when the dynamic
> > EPP sysfs file was turned on.
> > 
> > Longer term; I also envision the scheduler influencing EPP values when
> > dynamic_epp is turned on.  The "platform profile" would be an "input" to
> > that decision making process (maybe giving a weighting?), not the only
> > lever.

Yes, the scheduler influencing the EPP values is something that I have
been wanting to explore as well. My idea was to use the nature of the
task + the load on the rq to determine the EPP value.

> > 
> > I haven't given any serious look at how to do this with the scheduler, I
> > wanted to lay the foundation first being dynamic EPP and raw EPP.
> >
> > So even if dynamic_epp isn't interesting "right now" for server because
> > the focus is around behavior for AC/DC, don't write it off just yet.
>

Fair enough.


-- 
Thanks and Regards
gautham.


  reply	other threads:[~2025-03-10  5:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04 15:23 [PATCH v2 0/5] amd-pstate Dynamic EPP and raw EPP Mario Limonciello
2025-03-04 15:23 ` [PATCH v2 1/5] cpufreq/amd-pstate: Add dynamic energy performance preference Mario Limonciello
2025-03-07  6:45   ` Gautham R. Shenoy
2025-03-11  6:34   ` Dhananjay Ugwekar
2025-03-18 19:08     ` Mario Limonciello
2025-03-12 12:16   ` Dhananjay Ugwekar
2025-03-18 19:36     ` Mario Limonciello
2025-03-19  3:43       ` Dhananjay Ugwekar
2025-03-19 16:50         ` Mario Limonciello
2025-03-19 17:13           ` Mario Limonciello
2025-03-04 15:23 ` [PATCH v2 2/5] cpufreq/amd-pstate: add kernel command line to override dynamic epp Mario Limonciello
2025-03-07  8:53   ` Gautham R. Shenoy
2025-03-04 15:23 ` [PATCH v2 3/5] cpufreq/amd-pstate: Add support for platform profile class Mario Limonciello
2025-03-07 16:22   ` Gautham R. Shenoy
2025-03-07 16:55     ` Mario Limonciello
2025-03-08  4:30       ` Mario Limonciello
2025-03-10  5:09         ` Gautham R. Shenoy [this message]
2025-03-18 19:07           ` Mario Limonciello
2025-03-04 15:23 ` [PATCH v2 4/5] cpufreq/amd-pstate: Add support for raw EPP writes Mario Limonciello
2025-03-04 15:23 ` [PATCH v2 5/5] cpufreq/amd-pstate-ut: Add a unit test for raw EPP Mario Limonciello

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=Z85z8MN8ncr2ye4r@BLRRASHENOY1.amd.com \
    --to=gautham.shenoy@amd.com \
    --cc=Dhananjay.Ugwekar@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=perry.yuan@amd.com \
    --cc=superm1@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.