From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751861Ab1ADOfx (ORCPT ); Tue, 4 Jan 2011 09:35:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27622 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751507Ab1ADOfv (ORCPT ); Tue, 4 Jan 2011 09:35:51 -0500 Date: Tue, 4 Jan 2011 15:28:05 +0100 From: Oleg Nesterov To: Peter Zijlstra Cc: Chris Mason , Frank Rowand , Ingo Molnar , Thomas Gleixner , Mike Galbraith , Paul Turner , Jens Axboe , Yong Zhang , linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 16/17] sched: Move the second half of ttwu() to the remote cpu Message-ID: <20110104142805.GA4347@redhat.com> References: <20101224122338.172750730@chello.nl> <20101224123743.303699501@chello.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101224123743.303699501@chello.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/24, Peter Zijlstra wrote: > > +static void > +ttwu_do_activate(struct rq *rq, struct task_struct *p, int wake_flags) > +{ > +#ifdef CONFIG_SMP > + if (task_cpu(p) != cpu_of(rq)) > + set_task_cpu(p, cpu_of(rq)); > +#endif This looks a bit suspicious. If this is called by sched_ttwu_pending() we are holding rq->lock, not task_rq_lock(). It seems, we can race with, say, migration thread running on task_cpu(). OK, p->state = TASK_WAKING protects us against, say, set_cpus_allowed_ptr() which does task_rq_lock(p) and thus checks task_is_waking(). But, at the same time, > +#ifdef CONFIG_SMP > +static void ttwu_queue_remote(struct task_struct *p, int cpu) > +{ > + struct task_struct *next = NULL; > + struct rq *rq = cpu_rq(cpu); > + > + for (;;) { > + struct task_struct *old = next; > + > + p->wake_entry = next; > + next = cmpxchg(&rq->wake_list, old, p); > + if (next == old) > + break; > + } > + > + if (!next) > + smp_send_reschedule(cpu); what if that cpu does set_cpus_allowed_ptr(p) ? It spins with irq disabled. Once the caller, try_to_wake_up(), drops ->pi_lock it will wait for !task_is_waking() forever, no? Oleg.