From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763746AbcINPyh (ORCPT ); Wed, 14 Sep 2016 11:54:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54214 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754527AbcINPyf (ORCPT ); Wed, 14 Sep 2016 11:54:35 -0400 Date: Wed, 14 Sep 2016 17:53:45 +0200 From: Oleg Nesterov To: Cheng Chao Cc: mingo@kernel.org, peterz@infradead.org, tj@kernel.org, akpm@linux-foundation.org, chris@chris-wilson.co.uk, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] stop_machine: Avoid a sleep and wakeup in the stop_one_cpu() Message-ID: <20160914155345.GC21284@redhat.com> References: <1473497532-5440-1-git-send-email-cs.os.kernel@gmail.com> <1473818510-6779-1-git-send-email-cs.os.kernel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1473818510-6779-1-git-send-email-cs.os.kernel@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 14 Sep 2016 15:54:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/14, Cheng Chao wrote: > > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -1063,8 +1063,12 @@ static int migration_cpu_stop(void *data) > * holding rq->lock, if p->on_rq == 0 it cannot get enqueued because > * we're holding p->pi_lock. > */ > - if (task_rq(p) == rq && task_on_rq_queued(p)) > - rq = __migrate_task(rq, p, arg->dest_cpu); > + if (task_rq(p) == rq) { > + if (task_on_rq_queued(p)) > + rq = __migrate_task(rq, p, arg->dest_cpu); > + else > + p->wake_cpu = arg->dest_cpu; > + } Cough ;) again, I leave this to Peter... But imo this change should be documented or perhaps even separated. It looks fine to me, but this has nothing to do with "we can avoid a sleep+wakeup by doing a preemption" from the changelog. This is another improvement, and a small note in the changelog can unconfuse the reader of git blame/log. Oleg.