Re: [RFC PATCH 00/18] cgroup/cpuset: Enable runtime modification of

[Frederic Weisbecker <frederic@kernel.org>]

Le Fri, Aug 08, 2025 at 11:10:44AM -0400, Waiman Long a écrit :
> The "nohz_full" and "rcu_nocbs" boot command parameters can be used to
> remove a lot of kernel overhead on a specific set of isolated CPUs which
> can be used to run some latency/bandwidth sensitive workloads with as
> little kernel disturbance/noise as possible. The problem with this mode
> of operation is the fact that it is a static configuration which cannot
> be changed after boot to adjust for changes in application loading.
> 
> There is always a desire to enable runtime modification of the number
> of isolated CPUs that can be dedicated to this type of demanding
> workloads. This patchset is an attempt to do just that with an amount of
> CPU isolation close to what can be done with the nohz_full and rcu_nocbs
> boot kernel parameters.
> 
> This patch series provides the ability to change the set of housekeeping
> CPUs at run time via the cpuset isolated partition functionality.
> Currently, the cpuset isolated partition is able to disable scheduler
> load balancing and the CPU affinity of the unbound workqueue to avoid the
> isolated CPUs. This patch series will extend that with other kernel noises
> associated with the nohz_full boot command line parameter which has the
> following sub-categories:
>   - tick
>   - timer
>   - RCU
>   - MISC
>   - WQ
>   - kthread

Thanks for working on that, I'm about to leave for 2 weeks vacation so I
won't have the time to check this until I'm back.

However this series is highly conflicting with mine (cpuset/isolation: Honour
kthreads preferred affinity). Your patchset even redoes things I'm doing
(housekeeping cpumask update, RCU synchronization, HK_TYPE_DOMAIN to include
cpusets, etc...)

I have a v2 that is almost ready to post.

Wouldn't it be better to wait for it and its infrastructure changes before
proceeding with nohz_full?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs