Message-ID: <8e230c6d-ddd7-4385-865e-257168dc0057@arm.com>
Date: Thu, 15 Jan 2026 11:17:21 +0000
From: Christian Loehle <christian.loehle@....com>
To: Qais Yousef <qyousef@...alina.io>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 vincent.guittot@...aro.org, dietmar.eggemann@....com, rafael@...nel.org,
 peterz@...radead.org, pierre.gondois@....com, qperret@...gle.com,
 sven@...npeter.dev
Subject: Re: [PATCH 0/1] sched: Ignore overutilized by lone task on max-cap
 CPU

On 1/13/26 13:11, Qais Yousef wrote:
> On 12/30/25 09:30, Christian Loehle wrote:
>> I'm trying to deliver on my overdue promise of redefining overutilized state.
>> My investigation basically lead to redefinition of overutilized state
>> bringing very little hard improvements, while it comes with at least
>> some risk of worsening platforms and workload combinations I might've
>> overlooked, therefore I only concentrate on one, the least
>> controversial, for now.
> 
> What are the controversial bits?
> 
> This is a step forward, but not sure it is in the right direction. The concept
> of a *cpu* being overutilized === rd is overutilized no longer makes sense
> since misfit was decoupled from this logic which was the sole reason to
> require this check at CPU level.  Overutilized state is, rightly, set at the
> rootdomain level. And the check makes sense to be done at that level too by
> traversing the perf domains and seeing if we are in a state that requires
> moving tasks around. Which should be done in update_{sg,sd}_lb_stats() logic
> only.
> 
> I guess the difficult question (which might be what you're referring to as
> controversial), is at what point we can no longer pack (use EAS) and must
> distribute tasks around?

And that is precisely the 'controversial bits', I didn't want to touch them
with this patch specifically.
A more holistic redefinition of OU is still on the table, but it needs to
a) Still fulfill the requirements we want from it (guarantee of accurate PELT
values because compute capacity was 'always' provided, switching to throughput
maximization when needed).
b) Provide sufficient testing to convince us of not regressing anything majorly
on the quite diverse EAS platforms we have today.

I think $SUBJECT does a) and b) well, but of course it's for improving a
specific set of systems and doesn't address the issues with OU that have been
named in the past.

> 
> I think this question is limited by what the lb can do today. With push lb,
> I believe the current global lb is likely to be unnecessary in small systems
> (single LLC) since it can shuffle things around immediately to handle misfit
> and overload.
> 
> On top of that, what can the existing global lb do? I am not sure to be honest.
> The system has to have a number of long running tasks > num_cpus for it to be
> useful. But given util signal will lose its meaning under these circumstances,
> I am not sure the global lb can do a better job than push lb trying to move
> these tasks around. But it could do a more comprehensive job in one go? I'll
> defer to Vincent, he probably more able to answer this from the top of his
> head. But the answer to this question is the key to how we want to define this
> *system* is overutilized state.
> 
> Assuming this is on top of push lb, I believe something like below which will
> trigger overutilized only if all cpus are overutilized (ie system is nearly
> maxed out (has 20% or less headroom)) is a good starting point at least.

It's an approach, but it needs a lot of data to convince everyone that
push lb + much more liberal OU state outperforms current global LB OU.

Given this is not really about defining OU in a final state, any comments from
you and Vincent on $SUBJECT and the problem it's addressing would be 
much appreciated!

> [snip]

Powered by blists - more mailing lists