Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp510845pxb; Wed, 24 Feb 2021 07:56:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJzISxvb6kJVBmSDgH/XSjMH2zsk2iJcIqyeyCUfgf5qOqgS8e2vW39yB6OfLj68Q/gFNh+q X-Received: by 2002:aa7:dd49:: with SMTP id o9mr33696040edw.14.1614182167942; Wed, 24 Feb 2021 07:56:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614182167; cv=none; d=google.com; s=arc-20160816; b=J7od94uzNaBpZW2Bok+X17arz5Xu2hciu7i7j9EayyQ+2OtBGFUpHgraXB8SdWwMtu /06NAtLmndnu4A/HZ5iy2FBfoJBhQbkALqGYlojUWT3rrgPey8KYljnG6p3dND8pHhU0 Wcpk9FhIVf9ck2ZH4s0+QY+dZYWU9EJ66oV3steQ3GLIMKOIR0AaZNB/PmZ0UN0pqo6L dj0BE4iar8br8rEl0rXnUOzW3Zch/2E+7lNwu9T+A4h1Qfq6eagYBOTwtTn24Kt7hzU3 pbOb494EpnDFcOzHpHKB6ASa+e7Ab78pZyl1q+j6yfwUww1iNvYtDT/ThkLiuRW+LUWR +jeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from; bh=pNeLtv3+3wdllbTbTZYqquzOPN3/suWNAZdeXr4EgE8=; b=gI22SPzdC02P2713aNfe/5KjF5UdPLz8qlcm83FelsoYzWEK1ng2WYgUDyKhRoGcp5 PJO1uB+HEoobhOrwzxf1el0hCBAcboRzv3EeP6CbkNvPb20TqbiaXRrq0PWJYYPqSUxk TWFDPRkKvBDTzGYaQ8QKZZwzyzmlKzQOlIXH3SUuRtHSiBjVIbuLGF1srchhZLTlLgBp wk5Cuo6j5pDbUkAyDUjnWtLTqBpl2RHNIZVP8vWeQCtGI2GJ80ppFTcQGLj00a0xlW7T +57oi/6t2aJ0ua9sUke+pqiRr6iQZJj4m5z2lL6go61rhylmuU7HLTVDNH0VARlU99eq jYFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e2si1338902ejh.579.2021.02.24.07.55.35; Wed, 24 Feb 2021 07:56:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236335AbhBXPse (ORCPT + 99 others); Wed, 24 Feb 2021 10:48:34 -0500 Received: from foss.arm.com ([217.140.110.172]:36904 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232806AbhBXPgI (ORCPT ); Wed, 24 Feb 2021 10:36:08 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A1050101E; Wed, 24 Feb 2021 07:34:53 -0800 (PST) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6A5EE3F70D; Wed, 24 Feb 2021 07:34:52 -0800 (PST) From: Valentin Schneider To: Peter Zijlstra , Ingo Molnar , Thomas Gleixner Cc: Vincent Guittot , Mel Gorman , Dietmar Eggemann , linux-kernel@vger.kernel.org, peterz@infradead.org, Andi Kleen Subject: Re: [PATCH 6/6] sched: Simplify set_affinity_pending refcounts In-Reply-To: <20210224131355.724130207@infradead.org> References: <20210224122439.176543586@infradead.org> <20210224131355.724130207@infradead.org> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Wed, 24 Feb 2021 15:34:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/02/21 13:24, Peter Zijlstra wrote: > Now that we have set_affinity_pending::stop_pending to indicate if a > stopper is in progress, and we have the guarantee that if that stopper > exists, it will (eventually) complete our @pending we can simplify the > refcount scheme by no longer counting the stopper thread. > > Fixes: 6d337eab041d ("sched: Fix migrate_disable() vs set_cpus_allowed_ptr()") > Signed-off-by: Peter Zijlstra (Intel) > --- > @@ -2199,12 +2199,16 @@ static int affine_move_task(struct rq *r > push_task = get_task_struct(p); > } > > + /* > + * If there are pending waiters, but no pending stop_work, > + * then complete now. > + */ > pending = p->migration_pending; > - if (pending) { > - refcount_inc(&pending->refs); > + if (pending && !pending->stop_pending) { > p->migration_pending = NULL; > complete = true; > } > + > task_rq_unlock(rq, p, rf); > > if (push_task) { > @@ -2213,7 +2217,7 @@ static int affine_move_task(struct rq *r > } > > if (complete) > - goto do_complete; > + complete_all(&pending->done); We could've done this in the first place, right? I don't think this path actually needed to deal with the refcounts (at least not since we started counting the stoppers). Musings aside, I believe the above means, for migration_cpu_stop(): (pending != NULL) => (pending == p->migration_pending) Since, when ->stop_pending, only the stopper can uninstall p->migration_pending. This could simplify a few if's. Also, the fatty comment above affine_move_task() probably needs a bit of gardening: --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 9492f8eb242a..6f649aa2795c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2165,16 +2165,21 @@ void do_set_cpus_allowed(struct task_struct *p, const struct cpumask *new_mask) * * (1) In the cases covered above. There is one more where the completion is * signaled within affine_move_task() itself: when a subsequent affinity request - * cancels the need for an active migration. Consider: + * occurs after the stopper bailed out due to the targeted task still being + * Migrate-Disable. Consider: * * Initial conditions: P0->cpus_mask = [0, 1] * - * P0@CPU0 P1 P2 - * - * migrate_disable(); - * + * CPU0 P1 P2 + * + * migrate_disable(); + * * set_cpus_allowed_ptr(P0, [1]); * + * + * migration_cpu_stop() + * is_migration_disabled() + * * set_cpus_allowed_ptr(P0, [0, 1]); * *