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

[Peng Wang <peng_wang@linux.alibaba.com>]

On Thu, Oct 15, 2026 at 04:13:49PM -0400, Waiman Long wrote:
> 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?

Hi Waiman,

The concern is placement-dependent performance variation between
vCPUs sold under the same specification. Customers do not see which
host CPU backs their vCPU, so such differences would appear as
unexplained variation within the same specification.

At full allocation, we want a consistent non-idle tick policy across
the allocated CPUs to avoid this additional source of variation.

> > 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.

Yes. We run cloud hosts with vCPU threads pinned one-to-one to host
CPUs. Some CPUs are kept outside nohz_full for housekeeping, but
they also provide vCPU capacity at full allocation. Dedicating them
exclusively to housekeeping would reduce the capacity available to
guests.

At full allocation, vCPUs also run on housekeeping CPUs, which
retain their non-idle tick. Allowing only the nohz_full CPUs to stop
the tick would introduce a placement-dependent difference in tick
behavior between vCPUs of the same specification.

We therefore want to restore the non-idle tick on those nohz_full
CPUs, accepting the extra tick overhead to remove this controllable
difference. Host-side background activity is limited in this
deployment, and we can tolerate the remaining housekeeping noise.

With spare capacity, we want to allow selected nohz_full CPUs to
stop the tick to reduce host scheduler-tick interference with guest
execution. This is an opportunistic optimization when capacity
permits.

Host allocation changes as customers acquire or release vCPUs, while
other customers' VMs continue running.

A nohz_full CPU hosting a remaining vCPU may still have that vCPU
thread as its only runnable task, whether the host is fully or
partially allocated. The existing tick dependencies therefore do
not express the desired change in policy.

The proposed control allows per-CPU runtime changes without taking
CPUs offline or changing the boot-time nohz_full set or other
isolation settings.

Thanks,
Peng

> 
> Cheers,
> Longman
>