All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>,
	Marco Crivellari <marco.crivellari@suse.com>,
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH wq/for-7.4 v3 3/3] workqueue: Rescale max_active domains once CPU topology is known
Date: Fri, 16 Oct 2026 07:21:07 -1000	[thread overview]
Message-ID: <9cf4e46be85ea324de482d8a4343e6e2@kernel.org> (raw)
In-Reply-To: <20261009-wq_final-v3-3-eb0b095b9de3@debian.org>

Hello, Breno.

The following is a Claude-generated review.

On Fri, Oct 09, 2026 at 05:18:36AM -0700, Breno Leitao wrote:
> per-node max_active. With one CPU online both domains were equal, so
> saved_max_active is still the max_active the workqueue was created with
> and can be passed back as is.

Nothing guarantees that every workqueue on the list was created with one
CPU online. wq_init_max_active() runs before __alloc_workqueue() takes
wq_pool_mutex, so a workqueue can be created while smp_init() brings CPUs
up.

For a percpu workqueue, saved_max_active is the derived unbound limit:
percpu_max_active times the CPUs online at creation, capped at
WQ_MAX_ACTIVE. Passing it back as the percpu argument multiplies the live
per-CPU limit by that CPU count. A create_workqueue() workqueue created
with two CPUs online goes from 1 to 2. The same happens after a
workqueue_set_max_active() on a percpu workqueue in that window. No such
workqueue was found today, but nothing enforces it.

> +		mutex_lock(&wq->mutex);
> +		wq_init_max_active(wq, wq->saved_max_active);
> +		mutex_unlock(&wq->mutex);

Re-running the creation helper also:

1. Resets saved_min_active to min(max_active, WQ_DFL_MIN_ACTIVE), dropping
   any earlier workqueue_set_min_active(). async_init() is safe only
   because it runs right after workqueue_init_topology().

2. Writes the live limits directly with plain stores instead of
   publishing them through wq_adjust_max_active().

3. Takes N from wq_unbound_cpumask instead of wq_nr_effective_cpus(),
   unlike the setters.

4. Takes wq->mutex a second time right before the existing
   wq_update_node_max_active() section.

Maybe, under one wq->mutex section, rederive only the saved limits of the
domain the workqueue isn't using from the one it is, with the setters'
conversion and wq_nr_effective_cpus(), and then call
wq_adjust_max_active()? That could be a helper shared with the setters,
and this patch might then fold into 2/3.

Thanks.

-- 
tejun

      reply	other threads:[~2026-10-16 17:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 12:18 [PATCH wq/for-7.4 v3 0/3] workqueue: Keep max_active and percpu_max_active in sync Breno Leitao
2026-10-09 12:18 ` [PATCH wq/for-7.4 v3 1/3] workqueue: Move the initial max_active setup into a helper Breno Leitao
2026-10-16 17:21   ` Tejun Heo
2026-10-27 16:18     ` Breno Leitao
2026-10-09 12:18 ` [PATCH wq/for-7.4 v3 2/3] workqueue: Keep the limits of both max_active domains current Breno Leitao
2026-10-16 17:21   ` Tejun Heo
2026-10-27 17:38     ` Breno Leitao
2026-10-09 12:18 ` [PATCH wq/for-7.4 v3 3/3] workqueue: Rescale max_active domains once CPU topology is known Breno Leitao
2026-10-16 17:21   ` Tejun Heo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9cf4e46be85ea324de482d8a4343e6e2@kernel.org \
    --to=tj@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.crivellari@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.