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

[David Laight]

On Sun, 17 May 2026 16:44:01 +0100
Qais Yousef <qyousef@xxxxxxxxxxx> wrote:

> 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'd forgotten about that - even though I commented :-)

> 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.

If HZ is fixed at 1000 then there is no extra maths.

> I did have a stab at making HZ a variable and update TICK_NSEC to depend on it.

I do remember that, and thinking it would add a lot of extra maths.

...
> > 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 :)

I go for only allowing values that divide evenly into 1000.
That really only gives you interrupt rates of 1000Hz, 500Hz, 250Hz, 200Hz
and 100Hz (and maybe 50Hz).

-- David

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