linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: luca abeni <luca.abeni@santannapisa.it>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Paul E . McKenney" <paulmck@linux.ibm.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Quentin Perret <quentin.perret@arm.com>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Tommaso Cucinotta <tommaso.cucinotta@santannapisa.it>
Subject: Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup
Date: Wed, 8 May 2019 16:12:08 +0200	[thread overview]
Message-ID: <20190508161208.108caf26@nowhere> (raw)
In-Reply-To: <20190508131018.GJ6551@localhost.localdomain>

Hi Juri,

On Wed, 8 May 2019 15:10:18 +0200
Juri Lelli <juri.lelli@redhat.com> wrote:

> 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 :-)

I have no definitive answer about this :)

If we do not want to break EDF and its properties, migrations have to
be performed so that the "global EDF invariant" (schedule the m tasks
with earliest deadlines) is not broken (and capacity-based migrations
for non-idle cores risk to break this invariant).

In theory, we should do something like "schedule the earliest deadline
task on the fastest core", but this would require too many migrations
(and would require to migrate a task while it is executing, etc...)

I am convinced that doing the capacity-aware migrations when we have
idle cores helps to reduce migrations (avoiding "useless migrations")
when there are no idle cores, but I have no proof about this (just some
simple examples); this is why I say that I have no definitive answer...



				Luca

  reply	other threads:[~2019-05-08 14:12 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06  4:48 [RFC PATCH 0/6] Capacity awareness for SCHED_DEADLINE Luca Abeni
2019-05-06  4:48 ` [RFC PATCH 1/6] sched/dl: Improve deadline admission control for asymmetric CPU capacities Luca Abeni
2019-05-07 13:48   ` Quentin Perret
2019-05-07 13:55     ` Vincent Guittot
2019-05-07 14:02       ` Quentin Perret
2019-05-07 14:25     ` luca abeni
2019-05-07 14:31       ` Quentin Perret
2019-05-07 14:43         ` luca abeni
2019-07-08 11:22           ` Dietmar Eggemann
2019-07-08 15:05             ` Quentin Perret
2019-06-18 16:41   ` Alessio Balsini
2019-05-06  4:48 ` [RFC PATCH 2/6] sched/dl: Capacity-aware migrations Luca Abeni
2019-05-07 13:35   ` Quentin Perret
2019-05-07 14:17     ` luca abeni
2019-05-07 15:04       ` Quentin Perret
2019-05-07 14:10   ` Quentin Perret
2019-05-07 14:41     ` luca abeni
2019-05-07 15:02       ` Quentin Perret
2019-05-08  8:04   ` Juri Lelli
2019-05-08  8:17     ` luca abeni
2019-07-04 12:05   ` Dietmar Eggemann
2019-07-08  7:41     ` luca abeni
2019-07-08 10:41       ` Dietmar Eggemann
2019-05-06  4:48 ` [RFC PATCH 3/6] sched/dl: Try better placement even for deadline tasks that do not block Luca Abeni
2019-05-07 14:13   ` Quentin Perret
2019-05-07 16:00     ` Morten Rasmussen
2019-05-08  8:01   ` Juri Lelli
2019-05-08  8:14     ` luca abeni
2019-05-08  9:22       ` Juri Lelli
2019-07-08 13:55   ` Peter Zijlstra
2019-07-09 13:24     ` luca abeni
2019-07-09 13:42       ` Peter Zijlstra
2019-07-11 11:17         ` Dietmar Eggemann
2019-07-11 12:00           ` Peter Zijlstra
2019-07-11 15:33             ` Dietmar Eggemann
2019-07-09 14:44       ` Dietmar Eggemann
2019-05-06  4:48 ` [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup Luca Abeni
2019-05-08  9:08   ` Juri Lelli
2019-05-08  9:24     ` luca abeni
2019-05-08 12:05       ` Juri Lelli
2019-05-08 12:47         ` luca abeni
2019-05-08 13:10           ` Juri Lelli
2019-05-08 14:12             ` luca abeni [this message]
2019-05-06  4:48 ` [RFC PATCH 5/6] sched/dl: If the task does not fit anywhere, select the fastest core Luca Abeni
2019-05-06  4:48 ` [RFC PATCH 6/6] sched/dl: Try not to select a too fast core Luca Abeni
2019-05-07 15:57   ` Quentin Perret
2019-05-08  6:26     ` luca abeni
2019-05-09 13:46       ` Quentin Perret

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190508161208.108caf26@nowhere \
    --to=luca.abeni@santannapisa.it \
    --cc=bristot@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joel@joelfernandes.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@arm.com \
    --cc=paulmck@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=quentin.perret@arm.com \
    --cc=rafael@kernel.org \
    --cc=tommaso.cucinotta@santannapisa.it \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).