On 10/15/26 1:48 PM, Peng Wang wrote:
On Thu, Oct 15, 2026 at 12:00:25PM -0400, Waiman Long wrote:
On 10/15/26 8:43 AM, Peng Wang wrote:
Workloads and their need for periodic ticks can change after boot.
This series lets userspace choose at runtime which CPUs in the boot-time
nohz_full set retain the non-idle scheduler tick and which are permitted
to stop it, while preserving the existing isolation configuration.
The first patch adds a per-CPU tick dependency; the second exposes a
sysfs CPU list. Permission defaults to all nohz_full CPUs. Revocation
uses the existing asynchronous kick. Idle tick suppression is unchanged,
and policy persists across hotplug.
So you are basically setting up more nohz_full CPUs than the system actually
needs to use at the moment and so want to disable nohz/tick part of
nohz_full CPUs that don't need it. Can you elaborate more about the problems
solve by introducing this new behavior?
Hi Waiman,
Yes. We have CPU-pinned workloads that benefit from reduced periodic
tick interference. The desired tick policy changes with CPU allocation.
With spare capacity, we allow selected nohz_full CPUs to stop their
tick. When capacity is fully allocated, we prefer to retain the
non-idle periodic tick across CPUs, avoiding an additional difference
in tick interference between housekeeping and nohz_full CPUs.
What problem does that cause?
A CPU may still have only one runnable task in either case, so the
existing tick dependencies do not express this policy.
This series keeps the boot-time nohz_full CPU set, context tracking,
RCU offloading and housekeeping configuration unchanged. It only
controls whether those CPUs may stop their non-idle tick. The policy
can be changed without taking CPUs offline.
So the policy is to make the tick keeps running when there is only one
running task. Right? I am just not clear about the advantage of doing
that. Is there a use case that will require this particular feature? I
doubt this will get accepted unless there is a compelling reason to show
why we will want to have this feature.
Cheers,
Longman
