[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190731153027.GV31381@hirez.programming.kicks-ass.net>
Date: Wed, 31 Jul 2019 17:30:27 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Rik van Riel <riel@...riel.com>
Cc: linux-kernel@...r.kernel.org, kernel-team@...com, pjt@...gle.com,
dietmar.eggemann@....com, mingo@...hat.com,
morten.rasmussen@....com, tglx@...utronix.de,
mgorman@...hsingularity.net, vincent.guittot@...aro.org
Subject: Re: [PATCH 09/14] sched,fair: refactor enqueue/dequeue_entity
On Wed, Jul 31, 2019 at 11:03:01AM -0400, Rik van Riel wrote:
> I think I understand the problem you are pointing out, but if
> update_load_avg() keeps the load average for the runqueue unchanged
> (because that is rate limited to once a jiffy, and has been like that
> for a while), why would calc_group_shares() result in a different
> value than what it returned the last time?
>
> What am I overlooking?
I'm thinking you're thinking (3):
tg->weight * grq->avg.load_avg
shares = ------------------------------
tg->load_avg
Where: tg->load_avg ~= \Sum grq->avg.load_avg
Which is the straight forward shares calculation, and purely depends on
the load averages (which haven't been changed etc..)
But what we actually do is (6):
tg->weight * grq->avg.load_avg
shares = ---------------------------------------------------------------------------
tg->load_avg - grq->avg.load_avg + max(grq->load.weight, grq->avg.load_avg)
And even if tg->load_avg and grq->avg.load_avg haven't changed,
grq->load.weight most certainly has.
Powered by blists - more mailing lists