From: Juri Lelli <juri.lelli@redhat.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
Luca Abeni <luca.abeni@santannapisa.it>,
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: Fri, 10 Apr 2020 14:52:53 +0200 [thread overview]
Message-ID: <20200410125253.GE14300@localhost.localdomain> (raw)
In-Reply-To: <20200408095012.3819-4-dietmar.eggemann@arm.com>
Hi,
On 08/04/20 11:50, Dietmar Eggemann wrote:
> From: Luca Abeni <luca.abeni@santannapisa.it>
>
> The current SCHED_DEADLINE (DL) scheduler uses a global EDF scheduling
> algorithm w/o considering CPU capacity or task utilization.
> This works well on homogeneous systems where DL tasks are guaranteed
> to have a bounded tardiness but presents issues on heterogeneous
> systems.
>
> A DL task can migrate to a CPU which does not have enough CPU capacity
> to correctly serve the task (e.g. a task w/ 70ms runtime and 100ms
> period on a CPU w/ 512 capacity).
>
> Add the DL fitness function dl_task_fits_capacity() for DL admission
> control on heterogeneous systems. A task fits onto a CPU if:
>
> CPU original capacity / 1024 >= task runtime / task deadline
>
> Use this function on heterogeneous systems to try to find a CPU which
> meets this criterion during task wakeup, push and offline migration.
>
> On homogeneous systems the original behavior of the DL admission
> control should be retained.
>
> Signed-off-by: Luca Abeni <luca.abeni@santannapisa.it>
> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
> ---
> kernel/sched/cpudeadline.c | 14 +++++++++++++-
> kernel/sched/deadline.c | 18 ++++++++++++++----
> kernel/sched/sched.h | 15 +++++++++++++++
> 3 files changed, 42 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> index 5cc4012572ec..8630f2a40a3f 100644
> --- a/kernel/sched/cpudeadline.c
> +++ b/kernel/sched/cpudeadline.c
> @@ -121,7 +121,19 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
>
> if (later_mask &&
> cpumask_and(later_mask, cp->free_cpus, p->cpus_ptr)) {
> - return 1;
> + int cpu;
> +
> + if (!static_branch_unlikely(&sched_asym_cpucapacity))
> + return 1;
> +
> + /* Ensure the capacity of the CPUs fits the task. */
> + for_each_cpu(cpu, later_mask) {
> + if (!dl_task_fits_capacity(p, cpu))
> + cpumask_clear_cpu(cpu, later_mask);
> + }
> +
> + if (!cpumask_empty(later_mask))
> + return 1;
> } else {
> int best_cpu = cpudl_maximum(cp);
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 53b34a95e29e..e10adf1e3c27 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1604,6 +1604,7 @@ static int
> select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags)
> {
> struct task_struct *curr;
> + bool select_rq;
> struct rq *rq;
>
> if (sd_flag != SD_BALANCE_WAKE)
> @@ -1623,10 +1624,19 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags)
> * other hand, if it has a shorter deadline, we
> * try to make it stay here, it might be important.
> */
> - if (unlikely(dl_task(curr)) &&
> - (curr->nr_cpus_allowed < 2 ||
> - !dl_entity_preempt(&p->dl, &curr->dl)) &&
> - (p->nr_cpus_allowed > 1)) {
> + select_rq = unlikely(dl_task(curr)) &&
> + (curr->nr_cpus_allowed < 2 ||
> + !dl_entity_preempt(&p->dl, &curr->dl)) &&
> + p->nr_cpus_allowed > 1;
> +
> + /*
> + * We take into account the capacity of the CPU to
> + * ensure it fits the requirement of the task.
> + */
> + if (static_branch_unlikely(&sched_asym_cpucapacity))
> + select_rq |= !dl_task_fits_capacity(p, cpu);
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 ?
Thanks,
Juri
next prev parent reply other threads:[~2020-04-10 12:53 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 [this message]
2020-04-15 9:39 ` Dietmar Eggemann
2020-04-15 13:20 ` Juri Lelli
2020-04-15 16:42 ` luca abeni
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=20200410125253.GE14300@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=balsini@google.com \
--cc=bristot@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--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