linux-kernel - Re: [PATCH v2 3/3] cpufreq: intel_pstate: hybrid: Adjust energy model rules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gkE4i9VMfbwb9+F8KO+XecqXTis7atExbX3rfQvX2qOQ@mail.gmail.com>
Date: Wed, 15 Oct 2025 17:16:53 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Christian Loehle <christian.loehle@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux PM <linux-pm@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Lukasz Luba <lukasz.luba@....com>, 
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Yaxiong Tian <tianyaxiong@...inos.cn>
Subject: Re: [PATCH v2 3/3] cpufreq: intel_pstate: hybrid: Adjust energy model rules

On Wed, Oct 15, 2025 at 5:13 PM Christian Loehle
<christian.loehle@....com> wrote:
>
> On 10/15/25 14:48, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Instead of using HWP-to-frequency scaling factors for computing cost
> > coefficients in the energy model used on hybrid systems, which is
> > fragile, rely on CPU type information that is easily accessible now and
> > the information on whether or not L3 cache is present for this purpose.
> >
> > This also allows the cost coefficients for P-cores to be adjusted so
> > that they start to be populated somewhat earlier (that is, before
> > E-cores are loaded up to their full capacity).
> >
> > In addition to the above, replace an inaccurate comment regarding the
> > reason why the freq value is added to the cost in hybrid_get_cost().
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> >  drivers/cpufreq/intel_pstate.c |   37 +++++++++++++++----------------------
> >  1 file changed, 15 insertions(+), 22 deletions(-)
> >
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -933,11 +933,8 @@ static int hybrid_active_power(struct de
> >                              unsigned long *freq)
> >  {
> >       /*
> > -      * Create "utilization bins" of 0-40%, 40%-60%, 60%-80%, and 80%-100%
> > -      * of the maximum capacity such that two CPUs of the same type will be
> > -      * regarded as equally attractive if the utilization of each of them
> > -      * falls into the same bin, which should prevent tasks from being
> > -      * migrated between them too often.
> > +      * Create four "states" corresponding to 40%, 60%, 80%, and 100% of the
> > +      * full capacity.
> >        *
> >        * For this purpose, return the "frequency" of 2 for the first
> >        * performance level and otherwise leave the value set by the caller.
> > @@ -970,26 +967,22 @@ static bool hybrid_has_l3(unsigned int c
> >  static int hybrid_get_cost(struct device *dev, unsigned long freq,
> >                          unsigned long *cost)
> >  {
> > -     struct pstate_data *pstate = &all_cpu_data[dev->id]->pstate;
> > -
> > +     /* Facilitate load balancing between CPUs of the same type. */
> > +     *cost = freq;
> >       /*
> > -      * The smaller the perf-to-frequency scaling factor, the larger the IPC
> > -      * ratio between the given CPU and the least capable CPU in the system.
> > -      * Regard that IPC ratio as the primary cost component and assume that
> > -      * the scaling factors for different CPU types will differ by at least
> > -      * 5% and they will not be above INTEL_PSTATE_CORE_SCALING.
> > +      * Adjust the cost depending on CPU type.
> >        *
> > -      * Add the freq value to the cost, so that the cost of running on CPUs
> > -      * of the same type in different "utilization bins" is different.
> > -      */
> > -     *cost = div_u64(100ULL * INTEL_PSTATE_CORE_SCALING, pstate->scaling) + freq;
> > -     /*
> > -      * Increase the cost slightly for CPUs able to access L3 to avoid
> > -      * touching it in case some other CPUs of the same type can do the work
> > -      * without it.
> > +      * The idea is to start loading up LPE-cores before E-cores and start
> > +      * to populate E-cores when LPE-cores are utilized above 60% of the
> > +      * capacity.  Similarly, P-cores start to be populated when E-cores are
> > +      * utilized above 60% of the capacity.
> >        */
> > -     if (hybrid_has_l3(dev->id))
> > -             *cost += 2;
> > +     if (hybrid_get_cpu_type(dev->id) == INTEL_CPU_TYPE_ATOM) {
> > +             if (hybrid_has_l3(dev->id)) /* E-core */
> > +                     *cost += 2;
> > +     } else { /* P-core */
> > +             *cost += 4;
> > +     }
>
> Interesting, is there any reason in particular why you're looking to change this?
> Is it just performance because of the extra headroom? (I recall that your E-cores
> are always more efficient than your P-cores at comparable computing power).

Yes, it is performance mostly.

> How long does it take to trigger overutilized for you?

It depends, but sometimes it triggers really quickly due to LPE-core
load spikes.

> I still have the OU based on 'last idle time' observation patches lying around,
> although I haven't found the time to do more extensive testing if it doesn't
> regress some platform / workload combination. I will dust them off soon, although
> I'm not sure if they would help your case.
> Happy to try though if you had a particular workload in mind!

OK, good to know, thanks!