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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250222234749.swpcspu2x3htapck@airbuntu>
Date: Sat, 22 Feb 2025 23:47:49 +0000
From: Qais Yousef <qyousef@...alina.io>
To: David Laight <david.laight.linux@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>,
	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
Subject: Re: [PATCH] Kconfig.hz: Change default HZ to 1000

On 02/16/25 19:05, David Laight wrote:
> On Mon, 10 Feb 2025 00:19:15 +0000
> Qais Yousef <qyousef@...alina.io> wrote:
> 
> > The frequency at which TICK happens is very important from scheduler
> > perspective. There's a responsiveness trade-of that for interactive
> > systems the current default is set too low.
> 
> The problem I see is that most people use a kernel from one of the distributions.
> So you need to persuade them to change their default.
> Change the default 'default' won't necessarily have any effect.

True to some extent. I think Debian [1] relies on kernel's default, which is
a big distro. But the worry goes beyond that. I think 1K HZ is the modern
sensible default for all users. It shouldn't cause power issue given NOHZ and
other improvements. And the logic for context switch etc is no longer valid
IMHO.  Based on sched_ext saga it shows that people care a lot more on spending
more time to do the right decision given the complexity of today's systems. And
the systems I work on (mobile phones) I don't see impact on throughput. So IMHO
both sides of the arguments are no longer valid, but we continue to get common
discussions about latencies. This won't solve all problems, but will hopefully
send the right message to ensure most users switch to this too and address one
of the root causes for this common 'complaint'.

> 
> OTOH if you decouple the timer interrupt rate from HZ (or jiffies)
> then it becomes possible to boot time (or even run-time) change
> the timer interrupt rate.
> 
> So it makes much more sense to fix 'jiffies' as a 1ms counter and then
> configure the timer interrupt to be a number of ms/jiffies.
> 
> This would be similar all the simplifications that came about by making
> the high precision timestamps (etc) ns regardless of the actual
> resolution on any specific hardware.

Agreed. John is trying to do something similar but review comments show cased
teething issues. I did spend a long time working on converting HZ to be
a variable and switched a large number of users - but lost all this work sadly
when my machine died and forgot to push..

I think moving the default to follow what most folks should really be using is
the right thing for now IMHO. It doesn't force anyone to make an alternate
choice if they think they know really better.

[1] https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/config/config#L6389