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

Qais Yousef
2025-02-16T16:11:22Z

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@nvidia.com>

Thanks!

--
Qais Yousef