From: Kirill Tkhai <ktkhai@parallels.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
<linux-kernel@vger.kernel.org>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Ingo Molnar <mingo@kernel.org>, Paul Turner <pjt@google.com>,
<tkhai@yandex.ru>, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH 2/5] sched: Teach scheduler to understand ONRQ_MIGRATING state
Date: Tue, 22 Jul 2014 17:20:39 +0400 [thread overview]
Message-ID: <1406035239.3526.66.camel@tkhai> (raw)
In-Reply-To: <20140722082510.0086dd67@gandalf.local.home>
В Вт, 22/07/2014 в 08:25 -0400, Steven Rostedt пишет:
> On Tue, 22 Jul 2014 13:45:42 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> > > @@ -1491,10 +1491,14 @@ static void ttwu_activate(struct rq *rq, struct task_struct *p, int en_flags)
> > > static void
> > > ttwu_do_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
> > > {
> > > - check_preempt_curr(rq, p, wake_flags);
> > > trace_sched_wakeup(p, true);
> > >
> > > p->state = TASK_RUNNING;
> > > +
> > > + if (!task_queued(p))
> > > + return;
> >
> > How can this happen? we're in the middle of a wakeup, we're just added
> > the task to the rq and are still holding the appropriate rq->lock.
>
> I believe it can be in the migrating state. A comment would be useful
> here.
Sure, I'll update. Stupid question: should I resend all series or one message
in this thread is enough?
>
> > > @@ -4623,9 +4629,14 @@ int set_cpus_allowed_ptr(struct task_struct *p, const struct cpumask *new_mask)
> > > struct rq *rq;
> > > unsigned int dest_cpu;
> > > int ret = 0;
> > > -
> > > +again:
> > > rq = task_rq_lock(p, &flags);
> > >
> > > + if (unlikely(p->on_rq) == ONRQ_MIGRATING) {
> > > + task_rq_unlock(rq, p, &flags);
> > > + goto again;
> > > + }
> > > +
> > > if (cpumask_equal(&p->cpus_allowed, new_mask))
> > > goto out;
> > >
> >
> > That looks like a non-deterministic spin loop, 'waiting' for the
> > migration to finish. Not particularly nice and something I think we
> > should avoid for it has bad (TM) worst case behaviour.
>
> As this patch doesn't introduce the MIGRATING getting set yet, I'd be
> interested in this too. I'm assuming that the MIGRATING flag is only
> set and then cleared within an interrupts disabled section, such that
> the time is no more than a spinlock being taken.
>
> I would also add a cpu_relax() there too.
Sadly, I did't completely understand what you mean. Could you please explain
what has to be changed?
(I see wrong unlikely() place. It's an error. Is the other thing that there
is no task_migrating() method?)
Thanks,
Kirill
next prev parent reply other threads:[~2014-07-22 13:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140722102425.29682.24086.stgit@tkhai>
2014-07-22 11:30 ` [PATCH 1/5] sched: Wrapper for checking task_struct's .on_rq Kirill Tkhai
2014-07-22 11:30 ` [PATCH 2/5] sched: Teach scheduler to understand ONRQ_MIGRATING state Kirill Tkhai
2014-07-22 11:45 ` Peter Zijlstra
2014-07-22 12:24 ` Kirill Tkhai
2014-07-22 12:25 ` Steven Rostedt
2014-07-22 13:20 ` Kirill Tkhai [this message]
2014-07-24 19:03 ` Oleg Nesterov
2014-07-25 7:11 ` Kirill Tkhai
2014-07-22 11:30 ` [PATCH 3/5] sched: Remove double_rq_lock() from __migrate_task() Kirill Tkhai
2014-07-22 11:30 ` [PATCH 4/5] sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop() Kirill Tkhai
2014-07-25 0:04 ` Tim Chen
2014-07-25 7:05 ` Kirill Tkhai
2014-07-22 11:31 ` [PATCH 5/5] sched/fair: Remove double_lock_balance() from load_balance() Kirill Tkhai
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=1406035239.3526.66.camel@tkhai \
--to=ktkhai@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=tkhai@yandex.ru \
--cc=umgwanakikbuti@gmail.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