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: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Wei Wang <wvw@google.com>, Quentin Perret <qperret@google.com>,
	Alessio Balsini <balsini@google.com>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	Patrick Bellasi <patrick.bellasi@matbug.net>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Qais Yousef <qais.yousef@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] sched/deadline: Make DL capacity-aware
Date: Wed, 15 Apr 2020 18:42:03 +0200	[thread overview]
Message-ID: <20200415184203.50862783@sweethome> (raw)
In-Reply-To: <20200415132004.GF9767@localhost.localdomain>

Hi Juri,

On Wed, 15 Apr 2020 15:20:04 +0200
Juri Lelli <juri.lelli@redhat.com> wrote:
[...]
> > > I'm thinking that, while dl_task_fits_capacity() works well when
> > > selecting idle cpus, in this case we should consider the fact
> > > that curr might be deadline as well and already consuming some of
> > > the rq capacity.
> > > 
> > > Do you think we should try to take that into account, maybe using
> > > dl_rq->this_bw ?  
> > 
> > So you're saying that cpudl_find(..., later_mask) could return 1 (w/
> > best_cpu (cp->elements[0].cpu) in later_mask).
> > 
> > And that this best_cpu could be a non-fitting CPU for p.
> > 
> > This could happen if cp->free_cpus is empty (no idle CPUs) so we
> > take cpudl_find()'s else path and in case p's deadline <
> > cp->elements[0] deadline.
> > 
> > We could condition the 'return 1' on best_cpu fitting p.
> > 
> > But should we do this for cpudl_find(..., NULL) calls from
> > check_preempt_equal_dl() as well or will this break GEDF?  
> 
> So, even by not returning best_cpu, as above, if it doesn't fit p's bw
> requirement, I think we would be breaking GEDF, which however doesn't
> take asym capacities into account.

Well, gEDF could take asymmetric capacities into account by scheduling
the earliest deadline task on the fastest CPU (and the task with the
second earliest deadline on the second fastest CPU, and so on...)

But this could cause a lot of unneeded migrations (I tried to discuss
this issue in a previous OSPM presentation). My original approach to
work around this issue was to schedule a task on the slowest core on
which the task can fit (some experiments revealed that this heuristic
can approximate the gEDF behaviour without causing too many
migrations)... But this patch is not included on the current patchset,
and will be proposed later, after the most important patches have been
merged.


> OTOH, if we let p migrate to a cpu
> that can't suit it, it will still be missing its deadlines (plus it
> would be causing deadline misses on the task that was running on
> best_cpu).

In theory, if the task is scheduled on a core that is too slow for it
then we must allow faster cores to pull it later (when tasks with
earlier deadlines block). But this might be problematic, because it can
require to migrate a currently scheduled task.


			Luca

> 
> check_preempt_equal_dl() worries me less, as it is there to service
> corner cases (hopefully not so frequent).
> 


  reply	other threads:[~2020-04-15 16:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08  9:50 [PATCH 0/4] Capacity awareness for SCHED_DEADLINE Dietmar Eggemann
2020-04-08  9:50 ` [PATCH 1/4] sched/topology: Store root domain CPU capacity sum Dietmar Eggemann
2020-04-08 12:29   ` Vincent Guittot
2020-04-08 16:30     ` Dietmar Eggemann
2020-04-08 17:03       ` Vincent Guittot
2020-04-09 13:50         ` Dietmar Eggemann
2020-04-09 14:13           ` Vincent Guittot
2020-04-14  9:20             ` Dietmar Eggemann
2020-04-14 12:45         ` Quentin Perret
2020-04-14 15:27           ` Dietmar Eggemann
2020-04-14 15:43             ` Vincent Guittot
2020-04-08  9:50 ` [PATCH 2/4] sched/deadline: Improve admission control for asymmetric CPU capacities Dietmar Eggemann
2020-04-08 10:42   ` Valentin Schneider
2020-04-08 12:26     ` Dietmar Eggemann
2020-04-08 13:30     ` luca abeni
2020-04-08 14:23       ` Qais Yousef
2020-04-08 15:01       ` Valentin Schneider
2020-04-09 17:29         ` Dietmar Eggemann
2020-04-14 11:40           ` Qais Yousef
2020-04-14 14:29             ` Valentin Schneider
2020-04-14 15:41               ` Qais Yousef
2020-04-14 14:28           ` Valentin Schneider
2020-04-17 12:19           ` Juri Lelli
2020-04-17 14:55             ` Dietmar Eggemann
2020-04-17 15:08               ` Juri Lelli
2020-04-17 15:47                 ` Juri Lelli
2020-04-08  9:50 ` [PATCH 3/4] sched/deadline: Make DL capacity-aware Dietmar Eggemann
2020-04-10 12:52   ` Juri Lelli
2020-04-15  9:39     ` Dietmar Eggemann
2020-04-15 13:20       ` Juri Lelli
2020-04-15 16:42         ` luca abeni [this message]
2020-04-16 13:19           ` Juri Lelli
2020-04-08  9:50 ` [PATCH 4/4] sched/deadline: Implement fallback mechanism for !fit case Dietmar Eggemann
2020-04-09 10:25   ` Qais Yousef
2020-04-09 13:00     ` luca abeni
2020-04-09 14:55       ` Qais Yousef
2020-04-09 18:43         ` Dietmar Eggemann
2020-04-14 11:29           ` Qais Yousef

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=20200415184203.50862783@sweethome \
    --to=luca.abeni@santannapisa.it \
    --cc=balsini@google.com \
    --cc=bristot@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=peterz@infradead.org \
    --cc=pkondeti@codeaurora.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=wvw@google.com \
    /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).