Re: [PATCH] Kconfig.hz: Change default HZ to 1000

[Sean Christopherson <seanjc@google.com>]

On Sun, Feb 23, 2025, Ingo Molnar wrote:
> 
> * Andrea Righi <arighi@nvidia.com> wrote:
> 
> > On Wed, Feb 12, 2025 at 09:50:54AM -0500, Joel Fernandes wrote:
> > > On Mon, Feb 10, 2025 at 12:19:15AM +0000, Qais Yousef wrote:
> > ...
> > > > I believe HZ_250 was the default as a trade-off for battery power
> > > > devices that might not be happy with frequent TICKS potentially draining
> > > > the battery unnecessarily. But to my understanding the current state of
> > > 
> > > Actually, on x86, me and Steve did some debug on Chromebooks and we found
> > > that HZ_250 actually increased power versus higher HZ. This was because
> > > cpuidle governor changes C states on the tick, and by making it less
> > > frequent, the CPU could be in a shallow C state for longer.
> > 
> > FWIW, I found the same about power consumption when we decided to switch to
> > CONFIG_HZ=1000 in the Ubuntu kernel:
> > https://discourse.ubuntu.com/t/enable-low-latency-features-in-the-generic-ubuntu-kernel-for-24-04/42255
> 
> The "HZ=1000 reduces power consumption or keeps it the same" is 
> actually a pretty good argument to change the default to HZ=1000.
> 
> These experiments and numbers (if any) should be incorporated in the 
> changelog prominently - as actual data and the Kconfig decisions made 
> by major distros will, most of the time, be superior to meta analysis 
> that seems to be the changelog right now.

Speaking of which, has anyone done analysis when running as a VM?  I don't know
about other architectures, but on x86 at least, the tick (or more specifically,
(hr)timers) is the number one source of VM-Exits.  Off the cuff, I wouldn't any
meaningful difference in performance, but I also wouldn't be surprised if running
in a VM behaves differently than running on bare metal.

E.g. except for slice-of-hardware setups, MWAIT won't be exposed to the guest and
thus the cpuidle governor (in the guest) effectively has a binary decision (to
hlt, or not to hlt).