All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>,
	akpm@linux-foundation.org, rafael@kernel.org,
	peterz@infradead.org
Cc: Heiko Stuebner <heiko@sntech.de>,
	"moderated list:ARM/Rockchip SoC support"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC support"
	<linux-rockchip@lists.infradead.org>,
	"open list:CPU HOTPLUG" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] smpboot: Allow restricting per-CPU threads to a CPU mask
Date: Thu, 12 Nov 2026 18:40:23 +0100	[thread overview]
Message-ID: <87zeverlrs.ffs@fw13> (raw)
In-Reply-To: <af37c4e7811a86adafb2064e7cf4aa4f5090ab4b.1793660202.git.daniel.lezcano@oss.qualcomm.com>

On Tue, Nov 03 2026 at 00:09, Daniel Lezcano wrote:
> smpboot_register_percpu_thread() creates a thread for every online CPU
> and registers the descriptor for subsequent CPU hotplug operations.
> There is currently no way to restrict these threads to a subset of
> CPUs, even when the user only needs work performed on that subset.
>
> For example, an idle injection device targets a specific CPU mask.
> Creating threads outside that mask consumes resources unnecessarily.
> Supporting multiple such devices also requires each descriptor to
> manage only the threads associated with its own CPUs.
>
> Add an optional CPU mask to struct smp_hotplug_thread and apply it
> throughout the thread lifecycle. Registration creates threads only for
> online CPUs in the mask. CPU bring-up creates threads for selected
> CPUs that were offline at registration, while parking and unparking
> are restricted to the same mask.
>
> Apply the restriction to thread destruction as well, both during
> unregistration and registration failure cleanup. This is necessary
> when descriptors with disjoint masks share the same per-CPU task
> storage: tearing down one descriptor must not stop or clear threads
> owned by another descriptor.
>
> The caller must keep the mask valid and unchanged until the descriptor
> is unregistered. Callers sharing per-CPU task storage must ensure their
> masks do not overlap and serialize ownership changes themselves.

This really wants a built-in check which prevents overlapping
registrations for the same thread storage. It's easy enough to do:

smpboot_register_percpu_thread()

	if (!pt->cpumask)
		pt->cpu_mask = cpu_possible_mask;

	guard(cpus_read_lock)();
        guard(mutex)(&smpboot_threads_lock);
        list_for_each_entry(ht, &hotplug_threads, list) {
		if (ht->store != pt->store)
                	continue;
                if (WARN_ON_ONCE(cpumask_intersects(ht->cpumask, pt->cpumask)))
                	return -EBUSY;
        }
                
Hmm?

Thanks,

        tglx


WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@kernel.org>
To: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>,
	akpm@linux-foundation.org, rafael@kernel.org,
	peterz@infradead.org
Cc: Heiko Stuebner <heiko@sntech.de>,
	"moderated list:ARM/Rockchip SoC support"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC support"
	<linux-rockchip@lists.infradead.org>,
	"open list:CPU HOTPLUG" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] smpboot: Allow restricting per-CPU threads to a CPU mask
Date: Thu, 12 Nov 2026 18:40:23 +0100	[thread overview]
Message-ID: <87zeverlrs.ffs@fw13> (raw)
In-Reply-To: <af37c4e7811a86adafb2064e7cf4aa4f5090ab4b.1793660202.git.daniel.lezcano@oss.qualcomm.com>

On Tue, Nov 03 2026 at 00:09, Daniel Lezcano wrote:
> smpboot_register_percpu_thread() creates a thread for every online CPU
> and registers the descriptor for subsequent CPU hotplug operations.
> There is currently no way to restrict these threads to a subset of
> CPUs, even when the user only needs work performed on that subset.
>
> For example, an idle injection device targets a specific CPU mask.
> Creating threads outside that mask consumes resources unnecessarily.
> Supporting multiple such devices also requires each descriptor to
> manage only the threads associated with its own CPUs.
>
> Add an optional CPU mask to struct smp_hotplug_thread and apply it
> throughout the thread lifecycle. Registration creates threads only for
> online CPUs in the mask. CPU bring-up creates threads for selected
> CPUs that were offline at registration, while parking and unparking
> are restricted to the same mask.
>
> Apply the restriction to thread destruction as well, both during
> unregistration and registration failure cleanup. This is necessary
> when descriptors with disjoint masks share the same per-CPU task
> storage: tearing down one descriptor must not stop or clear threads
> owned by another descriptor.
>
> The caller must keep the mask valid and unchanged until the descriptor
> is unregistered. Callers sharing per-CPU task storage must ensure their
> masks do not overlap and serialize ownership changes themselves.

This really wants a built-in check which prevents overlapping
registrations for the same thread storage. It's easy enough to do:

smpboot_register_percpu_thread()

	if (!pt->cpumask)
		pt->cpu_mask = cpu_possible_mask;

	guard(cpus_read_lock)();
        guard(mutex)(&smpboot_threads_lock);
        list_for_each_entry(ht, &hotplug_threads, list) {
		if (ht->store != pt->store)
                	continue;
                if (WARN_ON_ONCE(cpumask_intersects(ht->cpumask, pt->cpumask)))
                	return -EBUSY;
        }
                
Hmm?

Thanks,

        tglx

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2026-11-12 17:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 23:09 [PATCH 0/2] powercap: idle_inject: Create threads on demand Daniel Lezcano
2026-11-02 23:09 ` Daniel Lezcano
2026-11-02 23:09 ` [PATCH 1/2] smpboot: Allow restricting per-CPU threads to a CPU mask Daniel Lezcano
2026-11-02 23:09   ` Daniel Lezcano
2026-11-03 11:48   ` Bradley Morgan
2026-11-03 11:48     ` Bradley Morgan
2026-11-12 17:40   ` Thomas Gleixner [this message]
2026-11-12 17:40     ` Thomas Gleixner
2026-11-12 18:03     ` Daniel Lezcano
2026-11-12 18:03       ` Daniel Lezcano
2026-11-02 23:09 ` [PATCH 2/2] powercap: idle_inject: Create per-CPU threads on registration Daniel Lezcano
2026-11-02 23:09   ` Daniel Lezcano
2026-11-05 18:46 ` [PATCH 0/2] powercap: idle_inject: Create threads on demand Daniel Lezcano
2026-11-05 18:46   ` Daniel Lezcano
2026-11-05 18:58   ` Andrew Morton
2026-11-05 18:58     ` Andrew Morton
2026-11-11  0:21     ` Thomas Gleixner
2026-11-11  0:21       ` Thomas Gleixner

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=87zeverlrs.ffs@fw13 \
    --to=tglx@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.lezcano@oss.qualcomm.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    /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.