Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2309761pxu; Fri, 18 Dec 2020 10:03:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJzPwh+WKlYHO/mTBdb5lBu9tAO0vbYa9rx7ABipD9WVEuhfVeUnP2/OraDA7knCSRrjlcoV X-Received: by 2002:a17:906:d9cf:: with SMTP id qk15mr5357901ejb.453.1608314639712; Fri, 18 Dec 2020 10:03:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608314639; cv=none; d=google.com; s=arc-20160816; b=Ad6Dj3izp/lnUb0kqA2/R5rReoTy6dfg+L2riwH6y0q8IGaiK66K2/C6teGrgzlodW PhuBueeFzdBPUbnjIw48XDn2aO14QLhlsHsnJ1r19bwxm1QbWqGB8hJKqNuhFjk15vjL VOHlGNbSL1/DztUnddxR0Wo/YzKG+6bB4R4MeoObh77g80COMQJdCbHzbBRaTDanrpcl QCUtw0pWgDqK8TqcB0KIY5vv80JwgqA3EwRKw6y/FF5C47lhsE+/OZEnxKZeufdfmmem Io4sEAC5c9734VAnTGncsU76oW+JOxAxChWRCgxkn/rbL6kaKWhrAK2FylsGXvST0gil uUvA== 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:in-reply-to:subject :cc:to:from:user-agent:references; bh=62ejr9jlX0iAoZ6s2hQNkJ6KGMryqEKxjWTLf29TC6A=; b=VmmYnaQcU4BFeJQitvyUdN9CZg56lLW6dI+LTEdZ0u2JX/wIOITdaQvES2dRpbGsUL pLLKV5otR8LDF4qSy5HX9Z0DnFNLzRiZDXL0/dj4KKckyUKhF56AAOCHF+Gv9ueUK9pi Y++tpjdItoRLDPX7whaZ5gvGugsUCgjN1rbYEZE2UvyihdgwhEQrq/YkADgucQT5xTyk s5RlZ7FN/XyXJ8GTyEzYeQYafLR/XL5RauytMOSOSJyHddmfBdhJNChK51AZrIeg6e8T hbu7JWWfjNMRcx2lt4TWOpMkC7AiOcSYh4Kjksx7F4N96EuC/VL5BxTMbaw6yvFNWXEK x/Ww== 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 11si7430537edv.53.2020.12.18.10.03.35; Fri, 18 Dec 2020 10:03:59 -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 S1727836AbgLRSAi (ORCPT + 99 others); Fri, 18 Dec 2020 13:00:38 -0500 Received: from foss.arm.com ([217.140.110.172]:39270 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726120AbgLRSAi (ORCPT ); Fri, 18 Dec 2020 13:00:38 -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 47C1830E; Fri, 18 Dec 2020 09:59:52 -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 23BFD3F66E; Fri, 18 Dec 2020 09:59:51 -0800 (PST) References: <20201218170919.2950-1-jiangshanlai@gmail.com> <20201218170919.2950-11-jiangshanlai@gmail.com> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Qian Cai , Vincent Donnefort , Lai Jiangshan , Tejun Heo Subject: Re: [PATCH -tip V2 10/10] workqueue: Fix affinity of kworkers when attaching into pool In-reply-to: <20201218170919.2950-11-jiangshanlai@gmail.com> Date: Fri, 18 Dec 2020 17:59:45 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/12/20 17:09, Lai Jiangshan wrote: > From: Lai Jiangshan > > When worker_attach_to_pool() is called, we should not put the workers > to pool->attrs->cpumask when there is not CPU online in it. > > We have to use wq_online_cpumask in worker_attach_to_pool() to check > if pool->attrs->cpumask is valid rather than cpu_online_mask or > cpu_active_mask due to gaps between stages in cpu hot[un]plug. > > So for that late-spawned per-CPU kworker case: the outgoing CPU should have > already been cleared from wq_online_cpumask, so it gets its affinity reset > to the possible mask and the subsequent wakeup will ensure it's put on an > active CPU. > > To use wq_online_cpumask in worker_attach_to_pool(), we need to protect > wq_online_cpumask in wq_pool_attach_mutex and we modify workqueue_online_cpu() > and workqueue_offline_cpu() to enlarge wq_pool_attach_mutex protected > region. We also put updating wq_online_cpumask and [re|un]bind_workers() > in the same wq_pool_attach_mutex protected region to make the update > for percpu workqueue atomically. > > Cc: Qian Cai > Cc: Peter Zijlstra > Cc: Vincent Donnefort > Link: https://lore.kernel.org/lkml/20201210163830.21514-3-valentin.schneider@arm.com/ > Acked-by: Valentin Schneider So an etiquette thing: I never actually gave an Acked-by. I did say it looked good to me, and that probably should've been bundled with a Reviewed-by, but it wasn't (I figured I'd wait for v2). Forging is bad, m'kay. When in doubt (e.g. someone says they're ok with your patch but don't give any Ack/Reviewed-by), just ask via mail or on IRC. For now, please make this a: Reviewed-by: Valentin Schneider > Acked-by: Tejun Heo > Signed-off-by: Lai Jiangshan > --- > kernel/workqueue.c | 32 +++++++++++++++----------------- > 1 file changed, 15 insertions(+), 17 deletions(-) > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > index 65270729454c..eeb726598f80 100644 > --- a/kernel/workqueue.c > +++ b/kernel/workqueue.c > @@ -310,7 +310,7 @@ static bool workqueue_freezing; /* PL: have wqs started freezing? */ > /* PL: allowable cpus for unbound wqs and work items */ > static cpumask_var_t wq_unbound_cpumask; > > -/* PL: online cpus (cpu_online_mask with the going-down cpu cleared) */ > +/* PL&A: online cpus (cpu_online_mask with the going-down cpu cleared) */ > static cpumask_var_t wq_online_cpumask; > > /* CPU where unbound work was last round robin scheduled from this CPU */ > @@ -1848,11 +1848,11 @@ static void worker_attach_to_pool(struct worker *worker, > { > mutex_lock(&wq_pool_attach_mutex); > > - /* > - * set_cpus_allowed_ptr() will fail if the cpumask doesn't have any > - * online CPUs. It'll be re-applied when any of the CPUs come up. > - */ > - set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask); > + /* Is there any cpu in pool->attrs->cpumask online? */ > + if (cpumask_intersects(pool->attrs->cpumask, wq_online_cpumask)) > + WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask) < 0); > + else > + WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, cpu_possible_mask) < 0); > > /* > * The wq_pool_attach_mutex ensures %POOL_DISASSOCIATED remains > @@ -5081,13 +5081,12 @@ int workqueue_online_cpu(unsigned int cpu) > int pi; > > mutex_lock(&wq_pool_mutex); > - cpumask_set_cpu(cpu, wq_online_cpumask); > > - for_each_cpu_worker_pool(pool, cpu) { > - mutex_lock(&wq_pool_attach_mutex); > + mutex_lock(&wq_pool_attach_mutex); > + cpumask_set_cpu(cpu, wq_online_cpumask); > + for_each_cpu_worker_pool(pool, cpu) > rebind_workers(pool); > - mutex_unlock(&wq_pool_attach_mutex); > - } > + mutex_unlock(&wq_pool_attach_mutex); > > /* update CPU affinity of workers of unbound pools */ > for_each_pool(pool, pi) { > @@ -5117,14 +5116,13 @@ int workqueue_offline_cpu(unsigned int cpu) > if (WARN_ON(cpu != smp_processor_id())) > return -1; > > - for_each_cpu_worker_pool(pool, cpu) { > - mutex_lock(&wq_pool_attach_mutex); > - unbind_workers(pool); > - mutex_unlock(&wq_pool_attach_mutex); > - } > - > mutex_lock(&wq_pool_mutex); > + > + mutex_lock(&wq_pool_attach_mutex); > cpumask_clear_cpu(cpu, wq_online_cpumask); > + for_each_cpu_worker_pool(pool, cpu) > + unbind_workers(pool); > + mutex_unlock(&wq_pool_attach_mutex); > > /* update CPU affinity of workers of unbound pools */ > for_each_pool(pool, pi) {