On Thu, Oct 29, 2026 at 03:02:13PM +0100, Frederic Weisbecker wrote: > Le Thu, Oct 29, 2026 at 02:41:28PM +0800, Peng Wang a 殂rit : > > Hi Frederic, > > > > > Do you mean that your database runs better when hosts CPUs are in > > > nohz_full? > > > > Yes. In our database tests, suppressing the host's non-idle > > periodic tick improved performance, with the rest of the host > > configuration unchanged. > > Out of curiosity, for such database tests, only the host tick is off, not the > guest > tick, right?
Yes. Only the host's non-idle tick policy changed. The guest did not use nohz_full, and its tick configuration was unchanged. > > > > But how does this new interface help? Ie: why is it worse to have all > > > CPUs in > > > > The tick policy itself can therefore affect guest performance. > > A large host runs VMs for many customers with different workloads. > > Customers create and release VMs independently, so the same host > > CPU can be reassigned to a different workload while other VMs > > remain running. > > > > We want to choose whether to retain the non-idle tick or allow its > > suppression for the workload currently assigned to each CPU, and > > revisit that choice when the CPU is reassigned. Per-CPU control > > lets us do this without rebooting or taking CPUs offline. > > Ok in that case, do you know about the current work in progress > to make nohz_full opt-able through cpusets? It implies taking the > target CPUs offline shortly but the policy is to be setup before VM > is launched, right? Not always. Waiman mentioned the cpuset work earlier; it could cover selecting the policy before a new VM starts. Some customers express a preference for host tick suppression through the management interface when changing workloads within a running VM. The host operator decides whether to allow suppression on the CPUs backing that VM. We want to support revisiting that decision while keeping those CPUs online and the VM running, with nohz_full membership unchanged. Could such an operation fit into the cpuset work? Thanks, Peng > > Thanks. > > -- > Frederic Weisbecker > SUSE Labs
