Messages in this thread | | | Date | Mon, 20 Feb 2023 11:13:18 +0100 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 0/1] sched/pelt: Change PELT halflife at runtime |
| |
On Thu, Feb 09, 2023 at 05:16:46PM +0100, Vincent Guittot wrote:
> > The results is very similar to PELT halflife reduction. The advantage is > > that 'util_est_faster' is only activated selectively when the runtime of > > the current task in its current activation is long enough to create this > > CPU util boost. > > IIUC how util_est_faster works, it removes the waiting time when > sharing cpu time with other tasks. So as long as there is no (runnable > but not running time), the result is the same as current util_est.
Uh.. it's double the speed, no? Even if there is no contention, the fake/in-situ pelt sum runs at double time and thus will ramp up faster than normal.
> util_est_faster makes a difference only when the task alternates > between runnable and running slices.
UTIL_EST was supposed to help mitigate some of that, but yes. Also note that _FASTER sorta sucks here because it starts from 0 every time, if it were to start from the state saved by util_est_dequeue(), it would ramp up faster still.
Patch has a comment along those lines I think.
> Have you considered using runnable_avg metrics in the increase of cpu > freq ? This takes into the runnable slice and not only the running > time and increase faster than util_avg when tasks compete for the same > CPU
Interesting! Indeed, that's boosting the DVFS for contention. And as deggeman's reply shows, it seems to work well.
I wonder if that one place where it regresses is exactly the case without contention.
| |