[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190508131018.GJ6551@localhost.localdomain>
Date: Wed, 8 May 2019 15:10:18 +0200
From: Juri Lelli <juri.lelli@...hat.com>
To: luca abeni <luca.abeni@...tannapisa.it>
Cc: linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
"Paul E . McKenney" <paulmck@...ux.ibm.com>,
Joel Fernandes <joel@...lfernandes.org>,
Quentin Perret <quentin.perret@....com>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Morten Rasmussen <morten.rasmussen@....com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Patrick Bellasi <patrick.bellasi@....com>,
Tommaso Cucinotta <tommaso.cucinotta@...tannapisa.it>
Subject: Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup
On 08/05/19 14:47, luca abeni wrote:
[...]
> Notice that all this logic is used only to select one of the idle cores
> (instead of picking the first idle core, we select the less powerful
> core on which the task "fits").
>
> So, running_bw does not provide any useful information, in this case;
> maybe this_bw can be more useful.
Ah, indeed.
However, what happens when cores are all busy? Can load balancing
decisions based on deadline values only break capacity awareness? (I
understand this is an RFC, so a "yes, something we need to look at" is
OK :-)
Powered by blists - more mailing lists