From: Scott Wood <swood@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Mel Gorman <mgorman@suse.de>,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH] sched/fair: Don't migrate with src_cpu == dst_cpu
Date: Mon, 07 Dec 2020 04:21:58 -0600 [thread overview]
Message-ID: <c707dab0a1ff71117663e9f1e35879f4345cbca4.camel@redhat.com> (raw)
In-Reply-To: <20201203084723.GG2414@hirez.programming.kicks-ass.net>
On Thu, 2020-12-03 at 09:47 +0100, Peter Zijlstra wrote:
> On Thu, Dec 03, 2020 at 12:04:49AM -0600, Scott Wood wrote:
> > Besides being a waste of time to try to move tasks to where they already
> > are, this avoids triggering the WARN_ON_ONCE(is_migration_disabled(p))
> > in set_task_cpu().
> >
> > Signed-off-by: Scott Wood <swood@redhat.com>
> > ---
> > Patch is against tip/master. Assertion was seen by running rteval on
> > the
> > RT tree.
> >
> > kernel/sched/fair.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index e7e21ac479a2..f443626164d4 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7574,7 +7574,8 @@ int can_migrate_task(struct task_struct *p, struct
> > lb_env *env)
> >
> > /* Prevent to re-select dst_cpu via env's CPUs: */
> > for_each_cpu_and(cpu, env->dst_grpmask, env->cpus) {
> > - if (cpumask_test_cpu(cpu, p->cpus_ptr)) {
> > + if (cpu != env->src_cpu &&
> > + cpumask_test_cpu(cpu, p->cpus_ptr)) {
> > env->flags |= LBF_DST_PINNED;
> > env->new_dst_cpu = cpu;
> > break;
>
> Do we have _any_ clue as to how we ended up in that situation? The above
> sounds like it should be a WARN and we should avoid getting here in the
> first place.
My initial impression was that there simply wasn't anything stopping it from
happening, but digging deeper it looks like it's specific to NUMA domains
with overlapping CPUs.
-Scott
prev parent reply other threads:[~2020-12-07 10:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 6:04 [PATCH] sched/fair: Don't migrate with src_cpu == dst_cpu Scott Wood
2020-12-03 8:47 ` Peter Zijlstra
2020-12-07 10:21 ` Scott Wood [this message]
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=c707dab0a1ff71117663e9f1e35879f4345cbca4.camel@redhat.com \
--to=swood@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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.