[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110526174903.GA19853@redhat.com>
Date: Thu, 26 May 2011 19:49:03 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Marc Zyngier <Marc.Zyngier@....com>,
Yong Zhang <yong.zhang0@...il.com>,
Ingo Molnar <mingo@...e.hu>,
Frank Rowand <frank.rowand@...sony.com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [BUG] "sched: Remove rq->lock from the first half of ttwu()"
locks up on ARM
On 05/26, Peter Zijlstra wrote:
>
> It has the extra cpu == smp_processor_id() check, but I'm not sure this
> whole case is worth the trouble.
Agreed, this case is very unlikely. Perhaps it makes the code more clear
though, up to you.
But, if we keep this check,
> @@ -2636,9 +2636,17 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> * to spin on ->on_cpu if p is current, since that would
> * deadlock.
> */
> - if (p == current) {
> - ttwu_queue(p, cpu);
> - goto stat;
> + if (cpu == smp_processor_id()) {
> + struct rq *rq;
> +
> + rq = __task_rq_lock(p);
> + if (p->on_cpu) {
> + ttwu_activate(rq, p, ENQUEUE_WAKEUP);
> + ttwu_do_wakeup(rq, p, wake_flags);
> + __task_rq_unlock(rq);
then why we re-check ->on_cpu? Just curious.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists