[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221103101124.GD10591@blackbody.suse.cz>
Date: Thu, 3 Nov 2022 11:11:24 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Josh Don <joshdon@...gle.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Valentin Schneider <vschneid@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] sched: async unthrottling for cfs bandwidth
On Wed, Nov 02, 2022 at 05:10:08PM -0700, Josh Don <joshdon@...gle.com> wrote:
> Without my patch, distribute_cfs_runtime() will unthrottle the
> cfs_rq's, and as you point out, it doesn't actually give them any real
> quota, it lets assign_cfs_rq_runtime() take care of that. But this
> happens asynchronously on those cpus. If they are idle, they wait for
> an IPI from the resched_curr() in unthrottled_cfs_rq(), otherwise they
> simply wait until potentially the next rescheduling point. So we are
> currently far from ever being guaranteed that the order the cpus pull
> actual quota via assign_cfs_rq_runtime() matches the order they were
> unthrottled from the list.
Thanks for breaking it down, I agree your change won't affect the
fairness substantially and my other points are clarified too.
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists