Re: [RFC PATCH 2/6] sched/uclamp: Simulate PELT decay in util_avg_uclamp
From: Hongyan Xia
Date: Tue Dec 05 2023 - 09:48:06 EST
On 04/12/2023 16:07, Vincent Guittot wrote:
On Wed, 4 Oct 2023 at 11:05, Hongyan Xia <Hongyan.Xia2@xxxxxxx> wrote:
From: Hongyan Xia <hongyan.xia2@xxxxxxx>
Because util_avg_uclamp is not directly managed by PELT, it lacks the
nice property of slowly decaying to a lower value, resulting in
performance degredation due to premature frequency drops.
That a very good reason for not doing this
This is not much different from util_guest and the "additive uclamp"
proposal in LPC 2023. The major difference is that I introduce a new
signal right beside util_avg (which then needs to have PELT behavior)
and they introduce signals in a way like util_est.
Now that I think about it, maybe my way is indeed too drastic, and maybe
the util_est way is better.
Add functions to decay root cfs utilization and tasks that are not on
the rq. This way, we get the benefits of PELT while still maintaining
uclamp. The rules are simple:
Nack. This just highlights that you are mixing different things and
then trying to make it work.
Please keep PELT out of uclamp_min/max
Well, like in my previous comment I think PELT is already a mixed signal
anyway, and treating it like it's not mixed with uclamp has already
shown many problems which need corner case code like 0 spare capacity
and uclamp filtering to make things work properly, and the code to fix
uclamp is still growing.
I will see if I can rework this series in a util_est style, and will
probably converge with the other two proposals, but fundamentally the
idea is that we don't have a pure PELT signal anyway. Achieving a PELT
value of X doesn't mean much if we don't know under what uclamp values
was it achieved, and having a clamped(X) on the side can be a very good
hint.
Hongyan