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

[Qais Yousef <qyousef@layalina.io>]

On 02/13/25 00:24, Saravana Kannan wrote:

> >  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
> 
> This is going to mess up power for tons of IOT and low power devices.

Why are you singling them out? Why is it worse for them compared to other
battery powered devices?

> I think we should leave the default alone and set the config in the
> device specific defconfig. Even on Android, for some use cases, this

I'll hold the mirror and tell you to keep the default for your systems in your
defconfigs. There has been a lot of discussion about sched latency and this is
a common cause especially when combined with schedutil. There's a lot of
accidental behaviors going and they are being addressed. The default should be
representative of what users of all classes are after. And responsiveness has
been a prime problem for a while.

> causes ~7% CPU power increase. This also causes more CPU wakeups

Have you analyzed the cause? Is this caused by something not mentioned in the
commit message? Accidental behaviors are not a reason not to move on to better
default. And managing system response time (particularly with schedutil) is an
ongoing area of improvement.

UiBench gets 13% and 54% less missed frames at the cost of 6.67% higher power.
There's a big performance impact because of the long TICK.

Phoronix (thankfully!) did a comparison too. The power impact wasn't noticeable
with some big gains in some benchmark. The things that got slightly worse were
regained by enabling PREEMPT_LAZY according to the comments.

	https://www.phoronix.com/news/Linux-250Hz-1000Hz-Kernel-2025

> because jiffy based timers that are set for t + 1ms, t + 2ms, t+ 3ms,
> t + 4ms would all get grouped into a t + 4ms HZ wakeup, but with 1000
> HZ timer, it'd cause 4 separate wakeups.

This has been called out in the commit message. You can't rely on accidental
behavior. If this is something that you think matters a lot you can send
a patch to do this coaleasing and decouple it from TICK. The right thing to do
is audit the drivers that are causing high wake rate. You can't prevent
improvements to the system because there are users that rely on wrong behavior.

> 
> I'd like to Nack this.

Please use the value you like in your defconfig if you have concerns. The new
default is a good indications for what people should be using by default. But
no one is forcing anyone to stick to them. The new default is what really the
majority of people want today, and this patch signals this clearly but doesn't
take away any other option from them.

--
Qais Yousef