From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA0DA28488F for ; Mon, 17 Nov 2025 03:05:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763348727; cv=none; b=GjWgslK4/V43nn6WTY/5moQya1hXGzHx2wWIqXWOr6aXq3OzRqOgKPmaRPwF4YwQta92S5/SZ1me9MELi98MFFgpkNj6vlSECYy9crqJ9NLU8Yla//uZG2Dk4i20c399N1qwi+4Rs0GuSM+pdCAX4FayJLnv/bpEQ1SIFP0pPXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763348727; c=relaxed/simple; bh=AUJ0qI42Kk2WL6oUM2NksrBbJRoRu9zi4TJ4qliAi1Q=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=iFggtseV1ToTqMrJIqsJt4ZTGjjBhLAreWCDTXLoqleVk/xW/7Y25JaCC5tY+h35hxRMefZ8KALKx75Vkrrl/sGgghOmJgmXDTE3BbifFJMMJPSxn7R26RH09H91kK70H7xqSA8tJTf5zKlpiMvaA7UjXf3/qxAXkNkNhwOkxmE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KKIzZ852; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KKIzZ852" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-3438d4ae152so4839414a91.1 for ; Sun, 16 Nov 2025 19:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763348725; x=1763953525; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=OSP7rNRnQa+eeSoHZte+ucCIej8+15ijTgo44p3aByE=; b=KKIzZ8529kAOre/7ELzI5E4uwuCSLYIb8S+tN+pFSyOTUiocTB5xqxSEYSDiy5os17 GQtjosuKsyKBzdV66Vum4TUxMl+wBtl3fV2sm/WxL5KoRrEmucznPeLZssh9jWjPvxWZ 7ALrC2Xb6FgCYFqbLvJ5+OaX0jyhi4it94Xs7sZr9cyQfR/Qtws3b1vz2FKQyEWMCLnC 8yTyJ9MywGMcHx3Lh5LaUa15bHdkdebg4uwZjmafdzd4f/oozd3u58y803KAu4+P0RIf IJHaIf1deNB9e8OGV+7rRO0FKUbKkrB8KFASI+fJ+AEkE6MvQoi3whkJqrbVVG7qVEQF vO1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763348725; x=1763953525; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=OSP7rNRnQa+eeSoHZte+ucCIej8+15ijTgo44p3aByE=; b=JzkJ8HT5nndtnYhjtBmJuFwLnpvdGskRuexunuVInU15y4UcWIjD52lxW3oOyTdnNR qGrqbZACr3onl71fLG2apNWoHYhgCRCwqmzBtXtZKHWE86udImRB8BCV6SAwzlu/rQe9 ZKDPaOpZ0PpgVNa3eYzMcCkWp99rL5XPbmuvC3fF8tb5rD2Mcs0wdRqsYKzY9lOrSpin iyVpEd0CKHgiNdtxJui2ncBfpwGlWXOmUo3XLzQOgg9j0ZOtIpSgrjPGYPOJU2Jqhcg7 fjpypLXs/UPaOEbhUzGqoDbWEFkPHlfos7plWV+saLuPq75tvw9ARAzI5DHbPzIcmJ86 q1kA== X-Gm-Message-State: AOJu0Yz6+++PDZQhhDflQAw0CytOdGF1HcW9+1DrsiV49iDDUOEQC472 VUViMas4nlTunL7EH34t7Fix20pSb3QNRLYUyBbJsGSnvAqFuIJFPJxi3EL7Rf/K X-Gm-Gg: ASbGncudffbFap3z1FJ4KRjteC/RYNjTI+dylXtmEssvP83SIqbFMMLjGmjXWrwmz6B +ZhL6PE99rHSY/IFVto9Gm7rarIDggy+1AjjFAQt0GzKdv1MNz6Js/l1x/PDUlABAWFudhi3m8o NTVPLeRlhxNdkgtL623GE/Q/0eqDCULvv88e/7IP2BZhzuGmXeSvgbTOYpumblNlR3/8jfwRrJq HQmJvgsWgT3raYN11dbgewv9IzJBeQyQnEEnMOZWl4sDsv79XDBovDE63opShQT+xs6YdeYDB8Q d17hec3Wh5HRj6vdTOu/1PAvmOohMAFUE//cc4xdCQFb6coWoMdojroyFVKm8ErXPueV5G+IXxJ yAbDHO8Zm+tujXMMLuF0XliRLOewUKBzmqSimQsqYOyqjyGuoNr+ykJhQ41JRCPRgdxFVgf1vnU WX X-Google-Smtp-Source: AGHT+IHuZMHGcCqbDN5Qa5dTS5r469p3cHp3P1+w5z2vjm02aEBltyrjgr2CBPShGazrCjPMSvXMEw== X-Received: by 2002:a17:90b:1b4c:b0:340:5c38:3a56 with SMTP id 98e67ed59e1d1-343fa77519amr13727587a91.37.1763348724885; Sun, 16 Nov 2025 19:05:24 -0800 (PST) Received: from localhost ([240b:4000:bb:1700:7b36:494d:5625:5a1]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-343e06fe521sm16606483a91.1.2025.11.16.19.05.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Nov 2025 19:05:24 -0800 (PST) From: Lai Jiangshan To: linux-kernel@vger.kernel.org Cc: Lai Jiangshan , Juri Lelli , Waiman Long , Tejun Heo , Lai Jiangshan Subject: [PATCH 1/3] workqueue: Update the rescuer's affinity only when it is detached Date: Mon, 17 Nov 2025 11:09:11 +0800 Message-Id: <20251117030913.3084-2-jiangshanlai@gmail.com> X-Mailer: git-send-email 2.19.1.6.gb485710b In-Reply-To: <20251117030913.3084-1-jiangshanlai@gmail.com> References: <20251117030913.3084-1-jiangshanlai@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Lai Jiangshan When a rescuer is attached to a pool, its affinity should be only managed by the pool. But updating the detached rescuer's affinity is still meaningful so that it will not disrupt isolated CPUs when it is to be waken up. But the commit d64f2fa064f8 ("kernel/workqueue: Let rescuers follow unbound wq cpumask changes") updates the affinity unconditionally, and causes some issues 1) it also changes the affinity when the rescuer is already attached to a pool, which violates the affinity management. 2) the said commit tries to update the affinity of the rescuers, but it misses the rescuers of the PERCPU workqueues, and isolated CPUs can be possibly disrupted by these rescuers when they are summoned. 3) The affinity to set to the rescuers should be consistent in all paths when a rescuer is in detached state. The affinity could be either wq_unbound_cpumask or unbound_effective_cpumask(wq). Related paths: rescuer's worker_detach_from_pool() update wq_unbound_cpumask update wq's cpumask init_rescuer() Both affinities are Ok as long as they are consistent in all paths. But using unbound_effective_cpumask(wq) requres much more code to maintain the consistency, and it doesn't make much sense since the affinity is only effective when the rescuer is not processing works. wq_unbound_cpumask is more favorable. Fix the 1) issue by testing rescuer->pool before updating with wq_pool_attach_mutex held. Fix the 2) issue by moving the rescuer's affinity updating code to the place updating wq_unbound_cpumask and make it also update for PERCPU workqueues. Partially cleanup the 3) consistency issue by using wq_unbound_cpumask. So that the path of "updating wq's cpumask" doesn't need to maintain it. and both the paths of "updating wq_unbound_cpumask" and "rescuer's worker_detach_from_pool()" use wq_unbound_cpumask. Cleanup for init_rescuer()'s consistency for affinity can be done in future. Cc: Juri Lelli Cc: Waiman Long Signed-off-by: Lai Jiangshan --- kernel/workqueue.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index af182a19a8b1..9da679c621dc 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -5411,11 +5411,6 @@ static void apply_wqattrs_commit(struct apply_wqattrs_ctx *ctx) /* update node_nr_active->max */ wq_update_node_max_active(ctx->wq, -1); - /* rescuer needs to respect wq cpumask changes */ - if (ctx->wq->rescuer) - set_cpus_allowed_ptr(ctx->wq->rescuer->task, - unbound_effective_cpumask(ctx->wq)); - mutex_unlock(&ctx->wq->mutex); } @@ -6974,6 +6969,11 @@ static int workqueue_apply_unbound_cpumask(const cpumask_var_t unbound_cpumask) if (!ret) { mutex_lock(&wq_pool_attach_mutex); cpumask_copy(wq_unbound_cpumask, unbound_cpumask); + /* rescuer needs to respect cpumask changes when it is not attached */ + list_for_each_entry(wq, &workqueues, list) { + if (wq->rescuer && !wq->rescuer->pool) + unbind_worker(wq->rescuer); + } mutex_unlock(&wq_pool_attach_mutex); } return ret; -- 2.19.1.6.gb485710b