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 2/6] sched/dl: Capacity-aware migrations
Date: Wed, 8 May 2019 10:17:57 +0200 [thread overview]
Message-ID: <20190508101757.1245ab84@nowhere> (raw)
In-Reply-To: <20190508080436.GF6551@localhost.localdomain>
On Wed, 8 May 2019 10:04:36 +0200
Juri Lelli <juri.lelli@redhat.com> wrote:
> Hi Luca,
>
> On 06/05/19 06:48, Luca Abeni wrote:
> > From: luca abeni <luca.abeni@santannapisa.it>
> >
> > Currently, the SCHED_DEADLINE scheduler uses a global EDF scheduling
> > algorithm, migrating tasks to CPU cores without considering the core
> > capacity and the task utilization. This works well on homogeneous
> > systems (SCHED_DEADLINE tasks are guaranteed to have a bounded
> > tardiness), but presents some issues on heterogeneous systems. For
> > example, a SCHED_DEADLINE task might be migrated on a core that has
> > not enough processing capacity to correctly serve the task (think
> > about a task with runtime 70ms and period 100ms migrated to a core
> > with processing capacity 0.5)
> >
> > This commit is a first step to address the issue: When a task wakes
> > up or migrates away from a CPU core, the scheduler tries to find an
> > idle core having enough processing capacity to serve the task.
> >
> > Signed-off-by: luca abeni <luca.abeni@santannapisa.it>
> > ---
> > kernel/sched/cpudeadline.c | 31 +++++++++++++++++++++++++++++--
> > kernel/sched/deadline.c | 8 ++++++--
> > kernel/sched/sched.h | 7 ++++++-
> > 3 files changed, 41 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> > index 50316455ea66..d21f7905b9c1 100644
> > --- a/kernel/sched/cpudeadline.c
> > +++ b/kernel/sched/cpudeadline.c
> > @@ -110,6 +110,22 @@ static inline int cpudl_maximum(struct cpudl
> > *cp) return cp->elements[0].cpu;
> > }
> >
> > +static inline int dl_task_fit(const struct sched_dl_entity *dl_se,
> > + int cpu, u64 *c)
> > +{
> > + u64 cap = (arch_scale_cpu_capacity(NULL, cpu) *
> > arch_scale_freq_capacity(cpu)) >> SCHED_CAPACITY_SHIFT;
> > + s64 rel_deadline = dl_se->dl_deadline;
> > + u64 rem_runtime = dl_se->dl_runtime;
>
> This is not the dynamic remaining one, is it?
Right; I preferred to split this in two patches so that if we decide to
use only the static task parameters (dl_deadline and dl_runtime) I can
simply drop a patch ;-)
Luca
>
> I see however 4/6.. lemme better look at that.
>
> Best,
>
> - Juri
next prev parent reply other threads:[~2019-05-08 8:18 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 [this message]
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
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=20190508101757.1245ab84@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.