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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z7z_hQ8hE9xbnBGn@google.com>
Date: Mon, 24 Feb 2025 15:23:49 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andrea Righi <arighi@...dia.com>, Joel Fernandes <joelagnelf@...dia.com>, 
	Qais Yousef <qyousef@...alina.io>, Thomas Gleixner <tglx@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.org>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Juri Lelli <juri.lelli@...hat.com>, Steven Rostedt <rostedt@...dmis.org>, 
	John Stultz <jstultz@...gle.com>, Saravana Kannan <saravanak@...gle.com>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Frederic Weisbecker <frederic@...nel.org>, 
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Kconfig.hz: Change default HZ to 1000

On Sun, Feb 23, 2025, Ingo Molnar wrote:
> 
> * Andrea Righi <arighi@...dia.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).