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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250216161118.m4c4m4jsjyskuwsc@airbuntu>
Date: Sun, 16 Feb 2025 16:11:18 +0000
From: Qais Yousef <qyousef@...alina.io>
To: Joel Fernandes <joelagnelf@...dia.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/12/25 09:50, Joel Fernandes wrote:
> On Mon, Feb 10, 2025 at 12:19:15AM +0000, Qais Yousef 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.
> 
> Another thing that screws up pretty badly at least with pre-EEVDF CFS is the
> extra lag that gets added to high nice value tasks due to the coarser tick
> causes low nice value tasks to get an even longer time slice. I caught this
> when tracing Android few years ago. ISTR, this was pretty bad almost to a
> point of defeating fairness. Not sure if that shows with EEVDF though.

There was a bug that Vincent fixed with sched_period in extreme scenarios. But
generally starvation problems are common with 4ms TICK when the CPU is
overloaded as it could be a long time before the task gets a chance to run
again.

> > NOHZ should be good enough to alleviate these concerns. And recent
> > addition of RCU_LAZY further helps with keeping TICK quite in idle
> > scenarios.
> > 
> > As pointed out to me by Saravana though, the longer TICK did indirectly
> > help with timer coalescing which means it could hide issues with
> > drivers/tasks asking for frequent timers preventing entry to deeper idle
> > states (4ms is a high value to allow entry to deeper idle state for many
> > systems). But one can argue this is a problem with these drivers/tasks.
> > And if the coalescing behavior is desired we can make it intentional
> > rather than accidental.
> 
> I am not sure how much coalescing of timer-wheel events matter. My impression
> is coalescing matters only for HRtimer since those can be more granular.

Bad usage of english from my side. It just they trigger accurately now and they
were accidentally deferred to the next jiffie which has 4ms granularity.

> >  kernel/Kconfig.hz | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/Kconfig.hz b/kernel/Kconfig.hz
> > index 38ef6d06888e..c742c9298af3 100644
> > --- a/kernel/Kconfig.hz
> > +++ b/kernel/Kconfig.hz
> > @@ -5,7 +5,7 @@
> >  
> >  choice
> >  	prompt "Timer frequency"
> > -	default HZ_250
> > +	default HZ_1000
> 
> Its fine with me, but I wonder who else cares about HZ_250 default. I
> certainly don't. And if someone really wants it for an odd reason, then can
> just adjust the config for themselves.

I think it is a common source of latency and performance and the arguments for
throughput and power are now outdated IMHO. Modern hardware and workloads are
different and time to modernize some default value to better suite the wider
audience.

> Acked-by: Joel Fernandes <joelagnelf@...dia.com>

Thanks!

--
Qais Yousef