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

[Waiman Long <longman@redhat.com>]

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