[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240425114949.GH12673@noisy.programming.kicks-ass.net>
Date: Thu, 25 Apr 2024 13:49:49 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Luis Machado <luis.machado@....com>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
linux-kernel@...r.kernel.org, kprateek.nayak@....com,
wuyun.abel@...edance.com, tglx@...utronix.de, efault@....de,
nd <nd@....com>, John Stultz <jstultz@...gle.com>
Subject: Re: [RFC][PATCH 08/10] sched/fair: Implement delayed dequeue
On Thu, Apr 25, 2024 at 12:42:20PM +0200, Peter Zijlstra wrote:
> > I wonder if the delayed dequeue logic is having an unwanted effect on the calculation of
> > utilization/load of the runqueue and, as a consequence, we're scheduling things to run on
> > higher OPP's in the big cores, leading to poor decisions for energy efficiency.
>
> Notably util_est_update() gets delayed. Given we don't actually do an
> enqueue when a delayed task gets woken, it didn't seem to make sense to
> update that sooner.
The PELT runnable values will be inflated because of delayed dequeue.
cpu_util() uses those in the @boost case, and as such this can indeed
affect things.
This can also slightly affect the cgroup case, but since the delay goes
away as contention goes away, and the cgroup case must already assume
worst case overlap, this seems limited.
/me goes ponder things moar.
Powered by blists - more mailing lists