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.