Re: [RFC PATCH 0/2] tick/nohz: Add runtime control of non-idle tick suppression

On 10/15/26 1:48 PM, Peng Wang wrote:

On Thu, Oct 15, 2026 at 12:00:25PM -0400, Waiman Long wrote:

quoted

On 10/15/26 8:43 AM, Peng Wang wrote:

quoted

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