* Re: [PATCH 13/15] sched/isolation: Implement sysfs interface for dynamic housekeeping
2026-03-30 11:46 ` [PATCH 13/15] sched/isolation: Implement sysfs interface for dynamic housekeeping Qiliang Yuan
@ 2026-03-30 18:34 ` Tejun Heo
2026-03-31 14:38 ` Waiman Long
1 sibling, 0 replies; 3+ messages in thread
From: Tejun Heo @ 2026-03-30 18:34 UTC (permalink / raw)
To: Qiliang Yuan
Cc: peterz, longman, cgroups, akpm, anna-maria, boqun.feng, bsegall,
dietmar.eggemann, frederic, hannes, jackmanb, jiangshanlai,
joelagnelf, josh, juri.lelli, linux-kernel, linux-kselftest,
linux-mm, mathieu.desnoyers, mgorman, mhocko, mingo, mingo,
neeraj.upadhyay, paulmck, qiang.zhang, rcu, rostedt, shuah,
surenb, tglx, urezki, vbabka, vincent.guittot, vschneid, ziy
cc'ing Waiman.
On Mon, Mar 30, 2026 at 07:46:20PM +0800, Qiliang Yuan wrote:
> On Wed, Mar 25, 2026 at 03:04:32PM +0100, Peter Zijlstra wrote:
> > Why? What was wrong with cpusets?
>
> This is the central point of the architecture. The distinction I was
> trying to address is:
>
> 1. Task Isolation (Current CPUSets):
> The `cpuset` subsystem (especially `cpuset.cpus.partition = isolated`)
> is excellent at managing task placement and load balancing. It
> ensures no user tasks are pushed to isolated CPUs.
>
> 2. Kernel Overhead Isolation (Housekeeping):
> Currently, `cpusets` do not manage kernel-internal overhead like RCU
> callbacks, timers, or unbound workqueues. These are managed by the
> global `housekeeping_cpumask`, which is settled at boot via
> `isolcpus`/`nohz_full` and is static.
>
> DHEI fills this second gap by making the housekeeping mask dynamic.
> However, I agree that a parallel sysfs interface is redundant.
>
> In V13, I will move the control interface to `cpuset`. The root cpuset
> will serve as the primary interface, allowing changes in the cpuset
> partition state to automatically trigger the migration of kernel
> housekeeping overhead. This achieves "Full Dynamic Isolation" (both tasks
> and kernel overhead) through a single, unified interface.
Please discuss with Frederic and Waiman first because they have been working
towards making cpuset to cover what cpuisol does. I don't think we want two
separate mechanisms for the same thing and don't see why this would need to
be its own thing when it has to be coupled with task isolation anyway.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 13/15] sched/isolation: Implement sysfs interface for dynamic housekeeping
2026-03-30 11:46 ` [PATCH 13/15] sched/isolation: Implement sysfs interface for dynamic housekeeping Qiliang Yuan
2026-03-30 18:34 ` Tejun Heo
@ 2026-03-31 14:38 ` Waiman Long
1 sibling, 0 replies; 3+ messages in thread
From: Waiman Long @ 2026-03-31 14:38 UTC (permalink / raw)
To: Qiliang Yuan, peterz
Cc: cgroups, akpm, anna-maria, boqun.feng, bsegall, dietmar.eggemann,
frederic, hannes, jackmanb, jiangshanlai, joelagnelf, josh,
juri.lelli, linux-kernel, linux-kselftest, linux-mm,
mathieu.desnoyers, mgorman, mhocko, mingo, mingo, neeraj.upadhyay,
paulmck, qiang.zhang, rcu, rostedt, shuah, surenb, tglx, tj,
urezki, vbabka, vincent.guittot, vschneid, ziy
On 3/30/26 7:46 AM, Qiliang Yuan wrote:
> On Wed, Mar 25, 2026 at 03:04:32PM +0100, Peter Zijlstra wrote:
>> Why? What was wrong with cpusets?
> This is the central point of the architecture. The distinction I was
> trying to address is:
>
> 1. Task Isolation (Current CPUSets):
> The `cpuset` subsystem (especially `cpuset.cpus.partition = isolated`)
> is excellent at managing task placement and load balancing. It
> ensures no user tasks are pushed to isolated CPUs.
>
> 2. Kernel Overhead Isolation (Housekeeping):
> Currently, `cpusets` do not manage kernel-internal overhead like RCU
> callbacks, timers, or unbound workqueues. These are managed by the
> global `housekeeping_cpumask`, which is settled at boot via
> `isolcpus`/`nohz_full` and is static.
My plan is to extend the cpuset isolated partition mechanism to isolate
other kernel noise currently covered by the nohz_full and manged_irq
boot command line. That will makes the HK_TYPE_KERNEL_NOISE cpumask
modifiable at run time. It is not a direct modification of the HK
cpumasks as advocated by this patch series but an indirect one via the
creation of the appropriate isolated cpuset partitions.
Cheers,
Longman
^ permalink raw reply [flat|nested] 3+ messages in thread