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

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

[Qais Yousef]

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.

With HRTICK now is default on, preemption checks are less of problem. But tasks
could need to migrate (specifically on HMP systems) and frequencies could need
updating for solo long running tasks.

The conversion is half complete. We need to invent a new jiffy (piffy?) and
move existing load balancing logic (and potentially other users if they want
to) to speed them up. BUT, with push load balancer patches circulating around,
I am not sure it is worth while or desired to speed it since we have a better
faster mechanism to keep the system balanced without the need for the 'heavy
handed' full load balance to trigger. The push lb can benefit from this ptick
too to ensure more responsiveness.

[1] https://lore.kernel.org/lkml/20250226000810.459547-1-qyousef@layalina.io/

Qais Yousef (3):
  sched/tick: Decouple sched_tick() from HZ
  sched/tick: Move TICK_NSEC users to PTICK_NSEC
  sched/tick: Turn on PTICK by default

 kernel/sched/clock.c             |  4 +-
 kernel/sched/core.c              | 78 +++++++++++++++++++++++++++++---
 kernel/sched/cpufreq_schedutil.c |  2 +-
 kernel/sched/fair.c              |  6 +--
 kernel/sched/features.h          |  8 ++++
 kernel/sched/sched.h             |  7 +++
 6 files changed, 93 insertions(+), 12 deletions(-)

-- 
2.34.1

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

[Qais Yousef]

Add new sched_feat(PTICK), Pseudo Tick, which runs at a more regular 1ms
interval when a task is running ensuring more timely update of sched
stats.

As discussed in previous attempt to change default HZ to 1000 [1], it is
very consequential on scheduler decisions. By decoupling sched_tick()
from HZ (timer tick), scheduler will no longer be limited by other TICK
implications and can be set to a constant value, 1000.

We could make it configurable, if folks think it can be useful, but this
seems to defeat the purpose of introducing it. We want fast regular
ticks. It can be turned off via sched_features for folks who don't want
the potential additional overhead. Defaults off for now.

PTICK will only be active when there are tasks running on the CPU. Given
HRTICK is now default on, it'd be more consequential for solo long
running tasks. When HRTICK off, it'd help with more precise time slices
when HZ is low.

When no tasks are running, sched_tick() will still be triggered from
regular TICK.

The actual interval is actually 1025us to ensure a PELT period (1024us)
has passed.

Since load balancer is tied to jiffies, we need additional work to
decouple it and help with faster reaction. Circulating patches to
introduce push load balancer could make this conversion unnecessary.

Other users of jiffies might find it useful to use the new ptick. But
any jiffies related conversion will be left out for now.

[1] https://lore.kernel.org/lkml/20250226000810.459547-1-qyousef@layalina.io/

Signed-off-by: Qais Yousef <qyousef@layalina.io>
---
 kernel/sched/core.c     | 78 +++++++++++++++++++++++++++++++++++++----
 kernel/sched/features.h |  7 ++++
 kernel/sched/sched.h    |  7 ++++
 3 files changed, 86 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b905805bbcbe..b47ac98ff42b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -890,7 +890,7 @@ static void __used hrtick_clear(struct rq *rq)
 }
 
 /*
- * High-resolution timer tick.
+ * High-resolution timer tick. Triggers at the end of next_task slice.
  * Runs from hardirq context with interrupts disabled.
  */
 static enum hrtimer_restart hrtick(struct hrtimer *timer)
@@ -1011,11 +1011,63 @@ static void hrtick_rq_init(struct rq *rq)
 	hrtimer_setup(&rq->hrtick_timer, hrtick, CLOCK_MONOTONIC,
 		      HRTIMER_MODE_REL_HARD | HRTIMER_MODE_LAZY_REARM);
 }
+
+static void ptick_clear(struct rq *rq)
+{
+	if (hrtimer_active(&rq->ptick_timer))
+		hrtimer_cancel(&rq->ptick_timer);
+}
+
+static void ptick_start(struct rq *rq)
+{
+	hrtimer_start(&rq->ptick_timer, ns_to_ktime(PTICK_NSEC),
+		      HRTIMER_MODE_ABS_PINNED_HARD);
+}
+
+static void ptick_ctx_switch(struct rq *rq,
+			     struct task_struct *prev, struct task_struct *next)
+{
+	if (is_idle_task(next))
+		ptick_clear(rq);
+
+	if (sched_feat(PTICK) && is_idle_task(prev))
+		ptick_start(rq);
+}
+
+void __sched_tick(void);
+
+/*
+ * High-resolution timer tick. Triggers regularly every PTICK_NSEC.
+ * Runs from hardirq context with interrupts disabled.
+ */
+static enum hrtimer_restart ptick(struct hrtimer *timer)
+{
+	struct rq *rq = container_of(timer, struct rq, ptick_timer);
+
+	WARN_ON_ONCE(cpu_of(rq) != smp_processor_id());
+
+	__sched_tick();
+
+	hrtimer_forward_now(timer, ns_to_ktime(PTICK_NSEC));
+
+	return HRTIMER_RESTART;
+}
+
+static void ptick_rq_init(struct rq *rq)
+{
+	hrtimer_setup(&rq->ptick_timer, ptick, CLOCK_MONOTONIC,
+		      HRTIMER_MODE_REL_HARD | HRTIMER_MODE_LAZY_REARM);
+}
 #else /* !CONFIG_SCHED_HRTICK: */
 static inline void hrtick_clear(struct rq *rq) { }
 static inline void hrtick_rq_init(struct rq *rq) { }
 static inline void hrtick_schedule_enter(struct rq *rq) { }
 static inline void hrtick_schedule_exit(struct rq *rq) { }
+static inline void ptick_clear(struct rq *rq) { }
+static inline void ptick_start(struct rq *rq) { }
+static inline void ptick_ctx_switch(struct rq *rq,
+				    struct task_struct *prev, struct task_struct *next) { }
+static inline void ptick_rq_init(struct rq *rq) { }
 #endif /* !CONFIG_SCHED_HRTICK */
 
 /*
@@ -5246,6 +5298,7 @@ static struct rq *finish_task_switch(struct task_struct *prev)
 	prev_state = READ_ONCE(prev->__state);
 	vtime_task_switch(prev);
 	perf_event_task_sched_in(prev, current);
+	ptick_ctx_switch(rq, prev, current);
 	finish_task(prev);
 	tick_nohz_task_switch();
 	finish_lock_switch(rq);
@@ -5637,11 +5690,7 @@ static int __init setup_resched_latency_warn_ms(char *str)
 }
 __setup("resched_latency_warn_ms=", setup_resched_latency_warn_ms);
 
-/*
- * This function gets called by the timer code, with HZ frequency.
- * We call it with interrupts disabled.
- */
-void sched_tick(void)
+void __sched_tick(void)
 {
 	int cpu = smp_processor_id();
 	struct rq *rq = cpu_rq(cpu);
@@ -5691,6 +5740,22 @@ void sched_tick(void)
 	}
 }
 
+/*
+ * This function gets called by the timer code, with HZ frequency or
+ * PTICK_NSEC. We call it with interrupts disabled.
+ */
+void sched_tick(void)
+{
+	int cpu = smp_processor_id();
+	struct rq *rq = cpu_rq(cpu);
+
+	/* Skip HZ calls unless there are no tasks running when PTICK is enabled */
+	if (sched_feat(PTICK) && rq->nr_running)
+		return;
+
+	__sched_tick();
+}
+
 #ifdef CONFIG_NO_HZ_FULL
 
 struct tick_work {
@@ -9017,6 +9082,7 @@ void __init sched_init(void)
 		rcuwait_init(&rq->hotplug_wait);
 #endif
 		hrtick_rq_init(rq);
+		ptick_rq_init(rq);
 		atomic_set(&rq->nr_iowait, 0);
 		fair_server_init(rq);
 #ifdef CONFIG_SCHED_CLASS_EXT
diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index 84c4fe3abd74..dcce2558ac21 100644
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -73,6 +73,13 @@ SCHED_FEAT(HRTICK, false)
 SCHED_FEAT(HRTICK_DL, false)
 #endif
 
+/*
+ * Pseudo Tick. Triggers when tasks are running on CPU. sched_tick() will run
+ * off of it when turned on. Will use regular TICK when no tasks are running or
+ * turned off.
+ */
+SCHED_FEAT(PTICK, false)
+
 /*
  * Decrement CPU capacity based on time not spent running tasks
  */
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 9f63b15d309d..78ea50905331 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1297,6 +1297,8 @@ struct rq {
 	ktime_t			hrtick_time;
 	ktime_t			hrtick_delay;
 	unsigned int		hrtick_sched;
+
+	struct hrtimer		ptick_timer;
 #endif
 
 #ifdef CONFIG_SCHEDSTATS
@@ -3070,6 +3072,11 @@ extern unsigned int sysctl_numa_balancing_hot_threshold;
 
 #ifdef CONFIG_SCHED_HRTICK
 
+/* PELT period is 1024us, add 1 to ensure one PELT period has passed */
+#define PTICK_USEC		(sched_feat(PTICK) ? (long)(USEC_PER_MSEC * 1.025) : TICK_USEC)
+#define PTICK_NSEC		(sched_feat(PTICK) ? (long)(NSEC_PER_MSEC * 1.025) : TICK_NSEC)
+#define PTICK_HZ		(sched_feat(PTICK) ? 1000 : HZ)
+
 /*
  * Use hrtick when:
  *  - enabled by features
-- 
2.34.1

[PATCH 2/3] sched/tick: Move TICK_NSEC users to PTICK_NSEC

[Qais Yousef]

Leave users in cputime.c and numa related load balance hooked to actual
TICK_NSEC. But the remainder of the references in kernel/sched were
converted to PTICK_NSEC.

Signed-off-by: Qais Yousef <qyousef@layalina.io>
---
 kernel/sched/clock.c             | 4 ++--
 kernel/sched/cpufreq_schedutil.c | 2 +-
 kernel/sched/fair.c              | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index 2ae4fbf13431..a331d9f47107 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -282,13 +282,13 @@ static __always_inline u64 sched_clock_local(struct sched_clock_data *scd)
 	/*
 	 * scd->clock = clamp(scd->tick_gtod + delta,
 	 *		      max(scd->tick_gtod, scd->clock),
-	 *		      scd->tick_gtod + TICK_NSEC);
+	 *		      scd->tick_gtod + PTICK_NSEC);
 	 */
 
 	gtod = scd->tick_gtod + __gtod_offset;
 	clock = gtod + delta;
 	min_clock = wrap_max(gtod, old_clock);
-	max_clock = wrap_max(old_clock, gtod + TICK_NSEC);
+	max_clock = wrap_max(old_clock, gtod + PTICK_NSEC);
 
 	clock = wrap_max(clock, min_clock);
 	clock = wrap_min(clock, max_clock);
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index ae9fd211cec1..d06527cf8d21 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -252,7 +252,7 @@ static bool sugov_iowait_reset(struct sugov_cpu *sg_cpu, u64 time,
 	s64 delta_ns = time - sg_cpu->last_update;
 
 	/* Reset boost only if a tick has elapsed since last request */
-	if (delta_ns <= TICK_NSEC)
+	if (delta_ns <= PTICK_NSEC)
 		return false;
 
 	sg_cpu->iowait_boost = set_iowait_boost ? IOWAIT_BOOST_MIN : 0;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 728965851842..2f8ed2eee2d7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -601,7 +601,7 @@ static inline bool entity_before(const struct sched_entity *a,
  * and this value should be no more than two lag bounds. Which puts it in the
  * general order of:
  *
- *	(slice + TICK_NSEC) << NICE_0_LOAD_SHIFT
+ *	(slice + PTICK_NSEC) << NICE_0_LOAD_SHIFT
  *
  * which is around 44 bits in size (on 64bit); that is 20 for
  * NICE_0_LOAD_SHIFT, another 20 for NSEC_PER_MSEC and then a handful for
@@ -822,7 +822,7 @@ static inline u64 cfs_rq_max_slice(struct cfs_rq *cfs_rq);
  * is possible -- by addition/removal/reweight to the tree -- to move V around
  * and end up with a larger lag than we started with.
  *
- * Limit this to either double the slice length with a minimum of TICK_NSEC
+ * Limit this to either double the slice length with a minimum of PTICK_NSEC
  * since that is the timing granularity.
  *
  * EEVDF gives the following limit for a steady state system:
@@ -831,7 +831,7 @@ static inline u64 cfs_rq_max_slice(struct cfs_rq *cfs_rq);
  */
 static s64 entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se, u64 avruntime)
 {
-	u64 max_slice = cfs_rq_max_slice(cfs_rq) + TICK_NSEC;
+	u64 max_slice = cfs_rq_max_slice(cfs_rq) + PTICK_NSEC;
 	s64 vlag, limit;
 
 	vlag = avruntime - se->vruntime;
-- 
2.34.1

[PATCH 3/3] sched/tick: Turn on PTICK by default

[Qais Yousef]

While load balancer is still hooked to actual TICK, but the few users
that relied on TICK_NSEC were converted and we should be able to switch
this on by default.

Yet to be seen load balancer conversion would be necessary if push load
balancer is merged soon.

Signed-off-by: Qais Yousef <qyousef@layalina.io>
---
 kernel/sched/features.h | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/features.h b/kernel/sched/features.h
index dcce2558ac21..4db90a266ce8 100644
--- a/kernel/sched/features.h
+++ b/kernel/sched/features.h
@@ -68,17 +68,18 @@ SCHED_FEAT(WAKEUP_PREEMPTION, true)
 #ifdef CONFIG_HRTIMER_REARM_DEFERRED
 SCHED_FEAT(HRTICK, true)
 SCHED_FEAT(HRTICK_DL, true)
-#else
-SCHED_FEAT(HRTICK, false)
-SCHED_FEAT(HRTICK_DL, false)
-#endif
 
 /*
  * Pseudo Tick. Triggers when tasks are running on CPU. sched_tick() will run
  * off of it when turned on. Will use regular TICK when no tasks are running or
  * turned off.
  */
+SCHED_FEAT(PTICK, true)
+#else
+SCHED_FEAT(HRTICK, false)
+SCHED_FEAT(HRTICK_DL, false)
 SCHED_FEAT(PTICK, false)
+#endif
 
 /*
  * Decrement CPU capacity based on time not spent running tasks
-- 
2.34.1

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

[Qais Yousef]

On 05/17/26 05:07, Qais Yousef 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.
> 
> With HRTICK now is default on, preemption checks are less of problem. But tasks
> could need to migrate (specifically on HMP systems) and frequencies could need
> updating for solo long running tasks.
> 
> The conversion is half complete. We need to invent a new jiffy (piffy?) and
> move existing load balancing logic (and potentially other users if they want
> to) to speed them up. BUT, with push load balancer patches circulating around,
> I am not sure it is worth while or desired to speed it since we have a better
> faster mechanism to keep the system balanced without the need for the 'heavy
> handed' full load balance to trigger. The push lb can benefit from this ptick
> too to ensure more responsiveness.

Err, this whole series is RFC. Forgot to add the tag, sorry.

> 
> [1] https://lore.kernel.org/lkml/20250226000810.459547-1-qyousef@layalina.io/
> 
> Qais Yousef (3):
>   sched/tick: Decouple sched_tick() from HZ
>   sched/tick: Move TICK_NSEC users to PTICK_NSEC
>   sched/tick: Turn on PTICK by default
> 
>  kernel/sched/clock.c             |  4 +-
>  kernel/sched/core.c              | 78 +++++++++++++++++++++++++++++---
>  kernel/sched/cpufreq_schedutil.c |  2 +-
>  kernel/sched/fair.c              |  6 +--
>  kernel/sched/features.h          |  8 ++++
>  kernel/sched/sched.h             |  7 +++
>  6 files changed, 93 insertions(+), 12 deletions(-)
> 
> -- 
> 2.34.1
> 

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

[David Laight]

On Sun, 17 May 2026 05:07:37 +0100
Qais Yousef <qyousef@layalina.io> 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.

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.

-- David

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@layalina.io> 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@google.com/

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@layalina.io> wrote:

> On 05/17/26 15:10, David Laight wrote:
> > On Sun, 17 May 2026 05:07:37 +0100
> > Qais Yousef <qyousef@layalina.io> 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@google.com/

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@layalina.io> wrote:
> 
> > On 05/17/26 15:10, David Laight wrote:
> > > On Sun, 17 May 2026 05:07:37 +0100
> > > Qais Yousef <qyousef@layalina.io> 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 :)

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

[Peter Zijlstra]

On Sun, May 17, 2026 at 05:07:37AM +0100, Qais Yousef wrote:
> With HRTICK now is default on,

.. for archs that use GENERIC_ENTRY. So for example, ARM64 doesn't (yet)
have this.

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

[Qais Yousef]

On 05/18/26 09:40, Peter Zijlstra wrote:
> On Sun, May 17, 2026 at 05:07:37AM +0100, Qais Yousef wrote:
> > With HRTICK now is default on,
> 
> .. for archs that use GENERIC_ENTRY. So for example, ARM64 doesn't (yet)
> have this.

I remembering trying to trace down the deps on HRTIMER_REARM_DEFERRED and then
got distracted.

HRTIMER on arm are cheap. Do we need this deps on generic entry?

Anyways. More reason to decouple I take :)

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

[Peter Zijlstra]

On Tue, May 19, 2026 at 01:42:56AM +0100, Qais Yousef wrote:
> On 05/18/26 09:40, Peter Zijlstra wrote:
> > On Sun, May 17, 2026 at 05:07:37AM +0100, Qais Yousef wrote:
> > > With HRTICK now is default on,
> > 
> > .. for archs that use GENERIC_ENTRY. So for example, ARM64 doesn't (yet)
> > have this.
> 
> I remembering trying to trace down the deps on HRTIMER_REARM_DEFERRED and then
> got distracted.
> 
> HRTIMER on arm are cheap. Do we need this deps on generic entry?
> 
> Anyways. More reason to decouple I take :)

ARM64 Generic Entry patches are en-route somewhere. I'll get sorted.