mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: Xuewen Yan <xuewen.yan94@gmail.com>, Qais Yousef <qyousef@layalina.io>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Xuewen Yan <xuewen.yan@unisoc.com>,
	mingo@redhat.com, juri.lelli@redhat.com, tj@kernel.org,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	linux-kernel@vger.kernel.org, rui.zhang@intel.com,
	di.shen@unisoc.com, ke.wang@unisoc.com,
	Christian Loehle <christian.loehle@arm.com>
Subject: Re: [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util()
Date: Thu, 19 Mar 2026 10:18:21 +0000	[thread overview]
Message-ID: <5a5d565b-33ac-4d5c-b0dd-1353324a6117@arm.com> (raw)
In-Reply-To: <CAB8ipk9QRQMtLF72Oozu=iLaNke1fKqGsPhTrCF3JEg+Ts2HkA@mail.gmail.com>

Hi Qais and Xuewen,

On 3/19/26 02:13, Xuewen Yan wrote:
> On Wed, Mar 18, 2026 at 9:44 PM Qais Yousef <qyousef@layalina.io> wrote:
>>
>> On 03/18/26 13:55, Vincent Guittot wrote:
>>> On Wed, 18 Mar 2026 at 13:47, Peter Zijlstra <peterz@infradead.org> wrote:
>>>>
>>>> On Wed, Mar 18, 2026 at 08:17:55PM +0800, Xuewen Yan wrote:
>>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>>>> index bf948db905ed..20adb6fede2a 100644
>>>>> --- a/kernel/sched/fair.c
>>>>> +++ b/kernel/sched/fair.c
>>>>> @@ -8198,7 +8198,12 @@ unsigned long effective_cpu_util(int cpu, unsigned long util_cfs,
>>>>>
>>>>>   unsigned long sched_cpu_util(int cpu)
>>>>>   {
>>>>> -     return effective_cpu_util(cpu, cpu_util_cfs(cpu), NULL, NULL);
>>>>> +     unsigned long util = scx_cpuperf_target(cpu);
>>>>> +
>>>>> +     if (!scx_switched_all())
>>>>> +             util += cpu_util_cfs(cpu);
>>>>> +
>>>>> +     return effective_cpu_util(cpu, util, NULL, NULL);
>>>>>   }
>>>>
>>>> This puts the common case of no ext muck into the slow path of that
>>>> static_branch.
>>>
>>> +1
>>> I was about to same
>>>
>>>>
>>>> This wants to be something like:
>>>>
>>>> unsigned long sched_cpu_util(int cpu)
>>>> {
>>>>          unsigned long util = cpu_util_cfs(cpu);
>>>>
>>>>          if (scx_enabled()) {
>>>>                  unsigned long scx_util = scx_cpuperf_target(cpu);
>>>
>>> also scx_cpuperf_target() does not reflect the utilization of the CPU
>>> but the targeted perfromance level
>>
>> Beside that, this sort of plug-and-play is a big concern. You picked up sched
>> ext and changed the behavior, then you'd need to get your thermal management to
>> work with that. Not retrospectively sprinkle these hacks around to force things
>> to work again.
> 
> In fact, I had considered this issue even before sending this patch.
> Our initial fix was to modify the thermal subsystem specifically,
> in cpufreq_cooling.c, when SCX is enabled, we stopped calling
> sched_cpu_util() and instead used idle-time-based calculation to
> obtain CPU util.
> 
> However, we later realized that sched_cpu_util() is used not only in
> cpufreq_cooling.c but also in dtpm_cpu.c.
> Since I’m not familiar with dtpm_cpu.c, I was hesitant to modify it.
> This led us to propose the current patch.
> Although scx_cpuperf_target may not accurately reflect the true CPU
> utilization, as Christian pointed out, it’s still better than having
> nothing at all.
> 
> That’s exactly why I marked this patch as RFC, I wasn’t sure whether
> the proper fix should be in cpufreq_cooling.c or in sched_cpu_util().
> It now seems clear that modifying only sched_cpu_util() is
> insufficient. Ideally, we should also update cpufreq_cooling.c, since
> we cannot guarantee that all SCX BPF programs will provide an accurate
> cpuperf_target.
> I’ll submit a follow-up patch to modify cpufreq_cooling.c shortly.
> 

If you refer to the utilization driven power estimation - I tend to
agree. You might remember, we had a few corner-cases due to that
design and I tried to address it differently [1][2].

Xuewen please send your proposal for the cpufreq_cooling.c and I will
have a look there. If there still be a need to fix it more deeply
then I can help with some deeper thermal changes.

Estimating the real CPU's power based on available information in the
kernel is really hard. Although, let's try to fix what you
observe in your devices.

Regards,
Lukasz

[1] 
https://lore.kernel.org/linux-pm/20210622075925.16189-1-lukasz.luba@arm.com/

[2] 
https://lore.kernel.org/linux-pm/20220406220809.22555-1-lukasz.luba@arm.com/

  parent reply	other threads:[~2026-03-19 10:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 12:17 Xuewen Yan
2026-03-18 12:47 ` Peter Zijlstra
2026-03-18 12:55   ` Vincent Guittot
2026-03-18 13:44     ` Qais Yousef
2026-03-19  2:13       ` Xuewen Yan
2026-03-19  7:09         ` Vincent Guittot
2026-03-19 10:18         ` Lukasz Luba [this message]
2026-03-24  1:32         ` Qais Yousef
2026-03-18 13:03   ` [PATCH] sched/cpufreq: Reorder so non-SCX is common path Christian Loehle
2026-03-19  1:08   ` [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util() Tejun Heo
2026-03-19  2:24     ` Xuewen Yan
2026-03-19  2:38       ` Xuewen Yan
2026-03-19  9:02     ` Peter Zijlstra
2026-03-19 10:01       ` Uros Bizjak
2026-03-19 10:26         ` Peter Zijlstra
2026-03-19 11:02           ` Uros Bizjak
2026-03-19 11:12             ` Peter Zijlstra
2026-03-19 11:19               ` Uros Bizjak
2026-03-19 11:33                 ` Peter Zijlstra
2026-03-19 11:22               ` Peter Zijlstra
2026-03-18 12:54 ` Christian Loehle
2026-03-19  1:21 ` Tejun Heo

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=5a5d565b-33ac-4d5c-b0dd-1353324a6117@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=di.shen@unisoc.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=ke.wang@unisoc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=rui.zhang@intel.com \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=xuewen.yan94@gmail.com \
    --cc=xuewen.yan@unisoc.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®