From: Frederic Weisbecker <frederic@kernel.org>
To: Waiman Long <llong@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
Phil Auld <pauld@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Danilo Krummrich <dakr@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Michal Koutny <mkoutny@suse.com>,
netdev@vger.kernel.org, Roman Gushchin <roman.gushchin@linux.dev>,
linux-block@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Eric Dumazet <edumazet@google.com>,
Michal Hocko <mhocko@suse.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Ingo Molnar <mingo@redhat.com>,
Chen Ridong <chenridong@huawei.com>,
cgroups@vger.kernel.org, linux-pci@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"David S . Miller" <davem@davemloft.net>,
Vlastimil Babka <vbabka@suse.cz>,
Marco Crivellari <marco.crivellari@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <axboe@kernel.dk>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Simon Horman <horms@kernel.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
linux-mm@kvack.org, Jakub Kicinski <kuba@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Gabriele Monaco <gmonaco@redhat.com>,
Muchun Song <muchun.song@linux.dev>,
Will Deacon <will@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Chen Ridong <chenridong@huaweicloud.com>
Subject: Re: [PATCH 00/33 v6] cpuset/isolation: Honour kthreads preferred affinity
Date: Mon, 12 Jan 2026 23:09:41 +0100 [thread overview]
Message-ID: <aWVxJVQYEWQiyO8Q@pavilion.home> (raw)
In-Reply-To: <437ccd7a-e839-4b40-840c-7c40d22f8166@redhat.com>
Le Mon, Jan 12, 2026 at 01:23:40PM -0500, Waiman Long a écrit :
> On 1/1/26 5:13 PM, Frederic Weisbecker wrote:
> > Hi,
> >
> > The kthread code was enhanced lately to provide an infrastructure which
> > manages the preferred affinity of unbound kthreads (node or custom
> > cpumask) against housekeeping constraints and CPU hotplug events.
> >
> > One crucial missing piece is cpuset: when an isolated partition is
> > created, deleted, or its CPUs updated, all the unbound kthreads in the
> > top cpuset are affine to _all_ the non-isolated CPUs, possibly breaking
> > their preferred affinity along the way
> >
> > Solve this with performing the kthreads affinity update from cpuset to
> > the kthreads consolidated relevant code instead so that preferred
> > affinities are honoured.
> >
> > The dispatch of the new cpumasks to workqueues and kthreads is performed
> > by housekeeping, as per the nice Tejun's suggestion.
> >
> > As a welcome side effect, HK_TYPE_DOMAIN then integrates both the set
> > from isolcpus= and cpuset isolated partitions. Housekeeping cpumasks are
> > now modifyable with specific synchronization. A big step toward making
> > nohz_full= also mutable through cpuset in the future.
> >
> > Changes since v5:
> >
> > * Add more tags
> >
> > * Fix leaked destroy_work_on_stack() (Zhang Qiao, Waiman Long)
> >
> > * Comment schedule_drain_work() synchronization requirement (Tejun)
> >
> > * s/Revert of/Inverse of (Waiman Long)
> >
> > * Remove housekeeping_update() needless (for now) parameter (Chen Ridong)
> >
> > * Don't propagate housekeeping_update() failures beyond allocations (Waiman Long)
> >
> > * Whitespace cleanup (Waiman Long)
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > kthread/core-v6
> >
> > HEAD: 811e87ca8a0a1e54eb5f23e71896cb97436cccdc
> >
> > Happy new year,
> > Frederic
>
> I don't see any major issue with this v6 version. There may be some minor
> issues that can be cleaned up later. Now the issue is which tree should this
> series go to as it touches a number of different subsystems with different
> maintainers.
It indeed crosses many subsystems. I would be fine if anybody takes it but
nobody volunteered so far.
The main purpose is to fix kthreads affinity (HK_TYPE_DOMAIN handling cpuset is
a bonus). And since I made the pull request myself to Linus when I introduced
kthreads managed affinity, I guess I could reiterate with this patchset. I
already pushed it to linux-next.
But if anybody wants to pull that to another tree, that's fine, just tell me
so that we synchronize to avoid duplication on linux-next.
Thanks.
--
Frederic Weisbecker
SUSE Labs
prev parent reply other threads:[~2026-01-12 22:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-01 22:13 Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 01/33] PCI: Prepare to protect against concurrent isolated cpuset change Frederic Weisbecker
2026-01-07 19:05 ` Bjorn Helgaas
2026-01-07 23:30 ` Frederic Weisbecker
2026-01-07 23:39 ` Bjorn Helgaas
2026-01-08 8:43 ` Jinhui Guo
2026-01-01 22:13 ` [PATCH 02/33] cpu: Revert "cpu/hotplug: Prevent self deadlock on CPU hot-unplug" Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 03/33] memcg: Prepare to protect against concurrent isolated cpuset change Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 04/33] mm: vmstat: " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 05/33] sched/isolation: Save boot defined domain flags Frederic Weisbecker
2026-01-12 18:03 ` Waiman Long
2026-01-01 22:13 ` [PATCH 06/33] cpuset: Convert boot_hk_cpus to use HK_TYPE_DOMAIN_BOOT Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 07/33] driver core: cpu: Convert /sys/devices/system/cpu/isolated " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 08/33] net: Keep ignoring isolated cpuset change Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 09/33] block: Protect against concurrent " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 10/33] timers/migration: Prevent from lockdep false positive warning Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 11/33] cpu: Provide lockdep check for CPU hotplug lock write-held Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 12/33] cpuset: Provide lockdep check for cpuset lock held Frederic Weisbecker
2026-01-12 1:43 ` Waiman Long
2026-01-12 17:53 ` Waiman Long
2026-01-01 22:13 ` [PATCH 13/33] sched/isolation: Convert housekeeping cpumasks to rcu pointers Frederic Weisbecker
2026-01-07 11:56 ` Simon Horman
2026-01-12 2:45 ` Waiman Long
2026-01-12 21:34 ` Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 14/33] cpuset: Update HK_TYPE_DOMAIN cpumask from cpuset Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 15/33] sched/isolation: Flush memcg workqueues on cpuset isolated partition change Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 16/33] sched/isolation: Flush vmstat " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 17/33] PCI: Flush PCI probe workqueue " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 18/33] cpuset: Propagate cpuset isolation update to workqueue through housekeeping Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 19/33] cpuset: Propagate cpuset isolation update to timers " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 20/33] timers/migration: Remove superfluous cpuset isolation test Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 21/33] cpuset: Remove cpuset_cpu_is_isolated() Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 22/33] sched/isolation: Remove HK_TYPE_TICK test from cpu_is_isolated() Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 23/33] PCI: Remove superfluous HK_TYPE_WQ check Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 24/33] kthread: Refine naming of affinity related fields Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 25/33] kthread: Include unbound kthreads in the managed affinity list Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 26/33] kthread: Include kthreadd to " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 27/33] kthread: Rely on HK_TYPE_DOMAIN for preferred affinity management Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 28/33] sched: Switch the fallback task allowed cpumask to HK_TYPE_DOMAIN Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 29/33] sched/arm64: Move fallback task " Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 30/33] kthread: Honour kthreads preferred affinity after cpuset changes Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 31/33] kthread: Comment on the purpose and placement of kthread_affine_node() call Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 32/33] kthread: Document kthread_affine_preferred() Frederic Weisbecker
2026-01-01 22:13 ` [PATCH 33/33] doc: Add housekeeping documentation Frederic Weisbecker
2026-01-12 18:23 ` [PATCH 00/33 v6] cpuset/isolation: Honour kthreads preferred affinity Waiman Long
2026-01-12 22:09 ` Frederic Weisbecker [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=aWVxJVQYEWQiyO8Q@pavilion.home \
--to=frederic@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huawei.com \
--cc=chenridong@huaweicloud.com \
--cc=dakr@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gmonaco@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=horms@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=llong@redhat.com \
--cc=marco.crivellari@suse.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox