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

[Qais Yousef]

On 05/17/26 17:09, David Laight wrote:
> 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).

I don't know. I think the HZ being tightly coupled with timers is fine and
makes sense logically. Trying to decouple this decades long assumptions might
come with a lot of un-intended consequences for something that can be solved
much easier by decoupling users that need better consistency and guarantees
across all configurations. I don't see a great benefit trying to play games
with jiffies. Load balancer will still need to do work to decouple from jiffy
in this instance too - though as I stated with push lb I think this work can be
skipped given we have a superior alternative soon hopefully.

The PTICK can be generalized to allow other users potentially who can benefit
from decoupling from timer TICK.

But I'll defer to the gurus :)