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
