[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240206152054.k3uskf3rhd4icmzt@airbuntu>
Date: Tue, 6 Feb 2024 15:20:54 +0000
From: Qais Yousef <qyousef@...alina.io>
To: Hongyan Xia <hongyan.xia2@....com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.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, David Dai <davidai@...gle.com>,
Saravana Kannan <saravanak@...gle.com>
Subject: Re: [RFC PATCH v2 0/7] uclamp sum aggregation
On 02/01/24 13:11, Hongyan Xia wrote:
> [1]: https://lore.kernel.org/all/20230331014356.1033759-1-davidai@google.com/
Their solution is not acceptable for the same reason yours isn't. Saravana and
David know this and we discussed at LPC. uclamp hints are limits and should not
be summed.
> [2]: https://android.googlesource.com/kernel/gs/+/refs/heads/android-gs-raviole-5.10-android12-d1/drivers/soc/google/vh/kernel/sched/fair.c#510
I think I clarified several times so far that this is not related to uclamp.
Could you please refrain from referring to it again in the future? This is
misleading and neither helps your cause nor its cause. The fact that you're
relating to it makes me very worried as both links demonstrate lack of
understanding/confusion of what uclamp is supposed to be.
Again, this solution is not acceptable and you're moving things in the wrong
direction. We don't want to redesign what uclamp means, but fix some corner
cases. And you're doing the former not the latter.
Powered by blists - more mailing lists