linux-kernel - Re: [PATCH 00/33 v6] cpuset/isolation: Honour kthreads preferred affinity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <437ccd7a-e839-4b40-840c-7c40d22f8166@redhat.com>
Date: Mon, 12 Jan 2026 13:23:40 -0500
From: Waiman Long <llong@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>,
 LKML <linux-kernel@...r.kernel.org>
Cc: Tejun Heo <tj@...nel.org>, Phil Auld <pauld@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Lai Jiangshan
 <jiangshanlai@...il.com>, Danilo Krummrich <dakr@...nel.org>,
 Catalin Marinas <catalin.marinas@....com>, Michal Koutny <mkoutny@...e.com>,
 netdev@...r.kernel.org, Roman Gushchin <roman.gushchin@...ux.dev>,
 linux-block@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
 Eric Dumazet <edumazet@...gle.com>, Michal Hocko <mhocko@...e.com>,
 Bjorn Helgaas <bhelgaas@...gle.com>, Ingo Molnar <mingo@...hat.com>,
 Chen Ridong <chenridong@...wei.com>, cgroups@...r.kernel.org,
 linux-pci@...r.kernel.org, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "David S . Miller" <davem@...emloft.net>, Vlastimil Babka <vbabka@...e.cz>,
 Marco Crivellari <marco.crivellari@...e.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>,
 "Rafael J . Wysocki" <rafael@...nel.org>,
 Johannes Weiner <hannes@...xchg.org>, Simon Horman <horms@...nel.org>,
 Shakeel Butt <shakeel.butt@...ux.dev>, linux-mm@...ck.org,
 Jakub Kicinski <kuba@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 Gabriele Monaco <gmonaco@...hat.com>, Muchun Song <muchun.song@...ux.dev>,
 Will Deacon <will@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Chen Ridong <chenridong@...weicloud.com>
Subject: Re: [PATCH 00/33 v6] cpuset/isolation: Honour kthreads preferred
 affinity

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.

Cheers,
Longman