mirror of https://lore.kernel.org/lkml/
 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 2/3] workqueue: Keep the limits of both max_active domains current
Date: Fri, 16 Oct 2026 07:21:06 -1000	[thread overview]
Message-ID: <654ec35be0b19332d2e605d69ed57910@kernel.org> (raw)
In-Reply-To: <20261009-wq_final-v3-2-eb0b095b9de3@debian.org>

Hello, Breno.

The following is a Claude-generated review.

On Fri, Oct 09, 2026 at 05:18:35AM -0700, Breno Leitao wrote:
> Given that we are introducing a new PERCPU affinity scope which will be
> able to do CM, we want to keep both values set, so, the transition from
> scopes would be able to succeed. This cannot be done under the flip, given
> this is RCU protected. See discussion at [1]

"CM" and "the flip" aren't defined, and concurrency management doesn't
come into this patch. The limits are WRITE_ONCE()/READ_ONCE() fields, not
RCU-protected. Maybe say directly that a later scope switch should land on
a sensible limit, so each setter derives the other domain?

> Use the scale function suggested by Tejun in [1].

The mapping is only in the cover letter, which doesn't land in git. Maybe
spell out the conversions here?

> N is the online CPUs the unbound backend of the workqueue may actually
> use. For a workqueue whose own cpumask has been narrowed, that is
> unbound_effective_cpumask(), not the global wq_unbound_cpumask -- the
> latter overcounts and makes percpu_max_active come out too low.
> wq_update_node_max_active() already distributes max_active the same way;
> match it.

N is sampled only when a setter runs. Narrowing the cpumask afterwards
through apply_workqueue_attrs() or sysfs redistributes max_active across
the nodes but leaves percpu_max_active alone. max_active 256 on 64 CPUs
gives percpu_max_active 8, and it stays 8 after narrowing to 4 CPUs where
64 would match. Nothing reads it yet. Should apply_wqattrs_commit()
rederive it too?

> +static int wq_user_max_active(struct workqueue_struct *wq)
> +{
> +	if (wq->flags & WQ_UNBOUND)
> +		return READ_ONCE(wq->saved_max_active);
> +
> +	return READ_ONCE(wq->saved_percpu_max_active);
> +}

The reads are marked but the setters write these fields with plain
stores. Maybe pair them with WRITE_ONCE()?

> -	if (!from_cancel && (wq->saved_max_active == 1 || wq->rescuer))
> +	if (!from_cancel && (wq_user_max_active(wq) == 1 || wq->rescuer))

The description doesn't explain this and the max_active_show() change.
For a percpu workqueue, saved_max_active now holds the derived unbound
limit, so these readers switch to the backend's own limit. Maybe add a
sentence?

> +	if (!installed_pwq(wq, -1))
> +		return wq_nr_online_cpus(wq_unbound_cpumask);

This tests for a percpu workqueue indirectly. Percpu workqueues never get
a dfl_pwq (apply_wqattrs_prepare() skips it for WQ_PERCPU), and unbound
ones always have one by the time a setter runs. Maybe test WQ_UNBOUND
directly?

> +	 * Which domain a pwq honours follows its pool, see
> +	 * pwq_tryinc_nr_active(). Keeping both current means a pwq is never
> +	 * metered against a limit nobody set.

Today a pwq's pool always matches its workqueue's backend, so this
describes the future PERCPU scope. Maybe state the contract instead, that
both are kept current so that a pwq on either kind of pool has a valid
limit?

Thanks.

-- 
tejun

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

Thread overview: 7+ 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-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 [this message]
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

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=654ec35be0b19332d2e605d69ed57910@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®