linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juri Lelli <juri.lelli@redhat.com>
To: Scott Wood <swood@redhat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH RT 5/8] sched/deadline: Reclaim cpuset bandwidth in .migrate_task_rq()
Date: Fri, 27 Sep 2019 10:11:41 +0200	[thread overview]
Message-ID: <20190927081141.GB31660@localhost.localdomain> (raw)
In-Reply-To: <20190727055638.20443-6-swood@redhat.com>

Hi Scott,

On 27/07/19 00:56, Scott Wood wrote:
> With the changes to migrate disabling, ->set_cpus_allowed() no longer
> gets deferred until migrate_enable().  To avoid releasing the bandwidth
> while the task may still be executing on the old CPU, move the subtraction
> to ->migrate_task_rq().
> 
> Signed-off-by: Scott Wood <swood@redhat.com>
> ---
>  kernel/sched/deadline.c | 67 +++++++++++++++++++++++--------------------------
>  1 file changed, 31 insertions(+), 36 deletions(-)
> 
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index c18be51f7608..2f18d0cf1b56 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1606,14 +1606,42 @@ static void yield_task_dl(struct rq *rq)
>  	return cpu;
>  }
>  
> +static void free_old_cpuset_bw_dl(struct rq *rq, struct task_struct *p)
> +{
> +	struct root_domain *src_rd = rq->rd;
> +
> +	/*
> +	 * Migrating a SCHED_DEADLINE task between exclusive
> +	 * cpusets (different root_domains) entails a bandwidth
> +	 * update. We already made space for us in the destination
> +	 * domain (see cpuset_can_attach()).
> +	 */
> +	if (!cpumask_intersects(src_rd->span, p->cpus_ptr)) {
> +		struct dl_bw *src_dl_b;
> +
> +		src_dl_b = dl_bw_of(cpu_of(rq));
> +		/*
> +		 * We now free resources of the root_domain we are migrating
> +		 * off. In the worst case, sched_setattr() may temporary fail
> +		 * until we complete the update.
> +		 */
> +		raw_spin_lock(&src_dl_b->lock);
> +		__dl_sub(src_dl_b, p->dl.dl_bw, dl_bw_cpus(task_cpu(p)));
> +		raw_spin_unlock(&src_dl_b->lock);
> +	}
> +}
> +
>  static void migrate_task_rq_dl(struct task_struct *p, int new_cpu __maybe_unused)
>  {
>  	struct rq *rq;
>  
> -	if (p->state != TASK_WAKING)
> +	rq = task_rq(p);
> +
> +	if (p->state != TASK_WAKING) {
> +		free_old_cpuset_bw_dl(rq, p);

What happens if a DEADLINE task is moved between cpusets while it was
sleeping? Don't we miss removing from the old cpuset if the task gets
migrated on wakeup?

Thanks,

Juri

  parent reply	other threads:[~2019-09-27  8:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-27  5:56 [RT PATCH 0/8] migrate disable fixes and performance Scott Wood
2019-07-27  5:56 ` [PATCH RT 1/8] sched: migrate_enable: Use sleeping_lock to indicate involuntary sleep Scott Wood
2019-07-29 13:26   ` Steven Rostedt
2019-07-27  5:56 ` [PATCH RT 2/8] sched: __set_cpus_allowed_ptr: Check cpus_mask, not cpus_ptr Scott Wood
2019-09-17 14:57   ` Sebastian Andrzej Siewior
2019-09-17 15:23     ` Scott Wood
2019-07-27  5:56 ` [PATCH RT 3/8] sched: Remove dead __migrate_disabled() check Scott Wood
2019-07-27  5:56 ` [PATCH RT 4/8] sched: migrate disable: Protect cpus_ptr with lock Scott Wood
2019-09-26 16:39   ` Sebastian Andrzej Siewior
2019-09-26 16:52     ` Scott Wood
2019-09-27 12:19       ` Sebastian Andrzej Siewior
2019-09-27 20:02         ` Scott Wood
2019-07-27  5:56 ` [PATCH RT 5/8] sched/deadline: Reclaim cpuset bandwidth in .migrate_task_rq() Scott Wood
2019-09-17 15:10   ` Sebastian Andrzej Siewior
2019-09-27  8:11   ` Juri Lelli [this message]
2019-09-27 16:40     ` Scott Wood
2019-09-30  7:12       ` Juri Lelli
2019-09-30 16:24         ` Scott Wood
2019-10-01  8:52           ` Juri Lelli
2019-10-09  6:25             ` Scott Wood
2019-10-09  7:27               ` Juri Lelli
2019-10-09 19:12                 ` Scott Wood
2019-10-10  8:18                   ` Juri Lelli
2019-07-27  5:56 ` [PATCH RT 6/8] sched: migrate_enable: Set state to TASK_RUNNING Scott Wood
2019-09-17 15:31   ` Sebastian Andrzej Siewior
2019-09-17 17:54     ` Scott Wood
2019-07-27  5:56 ` [PATCH RT 7/8] sched: migrate_enable: Use select_fallback_rq() Scott Wood
2019-09-17 16:00   ` Sebastian Andrzej Siewior
2019-09-24 18:05     ` Scott Wood
2019-07-27  5:56 ` [PATCH RT 8/8] sched: Lazy migrate_disable processing Scott Wood
2019-09-17 16:50   ` Sebastian Andrzej Siewior
2019-09-17 17:06     ` Scott Wood

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=20190927081141.GB31660@localhost.localdomain \
    --to=juri.lelli@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=bristot@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=swood@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.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).