From: Peng Wang <peng_wang@linux.alibaba.com>
To: Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@kernel.org>
Cc: Peng Wang <peng_wang@linux.alibaba.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Peter Zijlstra <peterz@infradead.org>,
Waiman Long <longman@redhat.com>, Tejun Heo <tj@kernel.org>,
He Rongguang <herongguang@linux.alibaba.com>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
driver-core@lists.linux.dev, linux-trace-kernel@vger.kernel.org,
cgroups@vger.kernel.org
Subject: [RFC PATCH v2 0/2] tick/nohz: Add per-CPU control of non-idle tick suppression
Date: Sat, 17 Oct 2026 21:13:40 +0800 [thread overview]
Message-ID: <cover.1792242566.git.peng_wang@linux.alibaba.com> (raw)
This series adds per-CPU control of non-idle tick suppression within
the boot-time nohz_full set. The policy can be changed without taking
CPUs offline.
Some cloud hosts pin vCPU threads one-to-one to host CPUs. At full
allocation, housekeeping CPUs also provide vCPU capacity and always
retain their non-idle tick. Operators want comparable performance for
otherwise equivalent vCPUs, regardless of CPU placement. Retaining the
non-idle tick on nohz_full CPUs as well avoids one placement-dependent
difference in host tick interference.
With spare capacity, selected nohz_full CPUs may stop the tick to reduce
host scheduler-tick interference with vCPUs. Allocation changes as VMs
are created or destroyed while other VMs remain running. A vCPU thread
may be the only runnable task in either state, so existing tick
dependencies do not express this policy.
The per-CPU nohz_tick_allowed boolean defaults to 1 (allowed). Writing
0 prevents non-idle tick suppression; writing 1 allows it, subject to
existing dependencies. Readback reports permission, not tick state.
This leaves idle tick suppression, nohz_full membership, context
tracking, RCU offloading and housekeeping configuration unchanged.
This series depends on the separately submitted nohz kick fix [2].
Testing used that fix together with this series in x86_64 KVM guests,
with NO_HZ_FULL enabled and disabled.
Changes since v1:
- Following Greg's sysfs feedback [1], replace the global CPU list with
a per-CPU boolean, removing the list-size and custom parsing issues.
- Rename nohz_full_allowed to nohz_tick_allowed, as suggested by Waiman.
- Explain the vCPU allocation use case and clarify permission semantics.
v1: https://lore.kernel.org/all/cover.1792067271.git.peng_wang@linux.alibaba.com/
[1] https://lore.kernel.org/all/2026101743-monotype-demeaning-f97b@gregkh/
[2] "tick/nohz: Requeue kicks flushed outside hardirq context"
Message-ID: <43668cf88d976084e2865ec07dea82b64ad402ba.1792240863.git.peng_wang@linux.alibaba.com>
Peng Wang (2):
tick/nohz: Add a policy dependency for full dynticks
cpu: Add per-CPU control of non-idle tick suppression
.../ABI/testing/sysfs-devices-system-cpu | 27 ++++++++++
drivers/base/cpu.c | 53 +++++++++++++++++++
include/linux/tick.h | 8 ++-
include/trace/events/timer.h | 3 +-
kernel/time/tick-sched.c | 42 +++++++++++++++
5 files changed, 130 insertions(+), 3 deletions(-)
base-commit: 70dd4ee72eb2d5793c62e71c14e3aba78e5a4e56
prerequisite-patch-id: 6036ece815f0ab92a0413d433675d5b240b7a8c1
--
2.47.0
next reply other threads:[~2026-10-17 13:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-17 13:13 Peng Wang [this message]
2026-10-17 13:13 ` [RFC PATCH v2 1/2] tick/nohz: Add a policy dependency for full dynticks Peng Wang
2026-10-17 13:13 ` [RFC PATCH v2 2/2] cpu: Add per-CPU control of non-idle tick suppression Peng Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1792242566.git.peng_wang@linux.alibaba.com \
--to=peng_wang@linux.alibaba.com \
--cc=anna-maria@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=frederic@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=herongguang@linux.alibaba.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.