Re: [PATCH 0/3] sched/tick: Decouple sched_tick() from HZ

[Qais Yousef]

On 05/17/26 15:10, David Laight wrote:
> On Sun, 17 May 2026 05:07:37 +0100
> Qais Yousef <qyousef@xxxxxxxxxxx> wrote:
> 
> > Previous attempt to make HZ 1000 the default [1] to help with scheduler
> > responsiveness didn't get merged. But maybe for the best, as I think this idea
> > of decoupling sched_tick() from HZ makes more sense. We shouldn't need to make
> > a choice between how often timers should trigger vs how often should the
> > scheduler update its stats/take decisions.
> 
> Have you also looked a decoupling HZ/jiffies from the timer interrupt rate?
> It ought to be reasonable set HZ to 1000 and to do 'jiffies += 4' when the
> timer interrupts 250 times a second.
> I'd expect most code to handle that fine.

John actually had a stab at that [1].

I am not sure we can fully say we don't care about what TICK_NSEC means. And
all the open coding with HZ.

I don't see value in the overall potential treewide conversion and the
potential compile time math becoming 'runtime overhead' complaint someone might
throw out.

I did have a stab at making HZ a variable and update TICK_NSEC to depend on it.
Unfortunately I lost that work. It required a lot of fix ups to the math and
conversions (which I did all of that). And since HZ is assumed to be
a label/define; when it is a variable lots of code fails to compile.  This is
where I was stuck getting all the conversion fixed when my machine died and
I forgot to save the work somewhere else and it was all gone.

> I know one architecture (forgotten which) traditionally used a 1024Hz clock,
> and some very old ones 60Hz; but I don't think Linux supports either.

Personally I think HZ=1000 is the only sensible option. But I am not going to
fight this battle :)

[1] https://lore.kernel.org/lkml/20250128063301.3879317-1-jstultz@xxxxxxxxxx/