[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cf221099-31f4-4de1-9418-a354f002e26e@arm.com>
Date: Tue, 5 Dec 2023 15:18:58 +0000
From: Hongyan Xia <hongyan.xia2@....com>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Qais Yousef <qyousef@...alina.io>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Morten Rasmussen <morten.rasmussen@....com>,
Lukasz Luba <lukasz.luba@....com>,
Christian Loehle <christian.loehle@....com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/6] sched: uclamp sum aggregation
On 04/12/2023 16:12, Vincent Guittot wrote:
> On Mon, 4 Dec 2023 at 02:48, Hongyan Xia <hongyan.xia2@....com> wrote:
>>
>> [...]
>>
>> Other shortcomings are not that critical, but the fact that uclamp_min's
>> effectiveness is divided by N under max aggregation I think is not
>> acceptable.
>
> Change EAS task placement policy in this case to take into account
> actual utilization and uclamp_min/max
Thank you. I agree. I want to emphasize this specifically because this
is exactly what I'm trying to do. The whole series can be rephrased in a
different way:
- The PELT signal is distorted when uclamp is active.
- Let's consider the [PELT, uclamp_min, uclamp_max] tuple.
- Always carrying all three variables is too much, but [PELT,
clamped(PELT)] is an approximation that works really well.
Of course, I'll explore if there's a way to make things less messy. I
just realized why I didn't do things util_est way but instead directly
clamping on PELT, it's because util_est boosts util_avg and can't work
for uclamp_max. I'll keep exploring options.
>> [...]
Powered by blists - more mailing lists