linux-kernel - Re: [PATCH v2 1/6] sched/eevdf: Fix HRTICK duration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXIBrpMDigZGUDYR@jlelli-thinkpadt14gen4.remote.csb>
Date: Thu, 22 Jan 2026 11:53:34 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, arnd@...db.de, anna-maria@...utronix.de,
	frederic@...nel.org, luto@...nel.org, mingo@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	vschneid@...hat.com, linux-kernel@...r.kernel.org,
	oliver.sang@...el.com
Subject: Re: [PATCH v2 1/6] sched/eevdf: Fix HRTICK duration

Hello,

On 21/01/26 17:20, Peter Zijlstra wrote:
> The nominal duration for an EEVDF task to run is until its deadline.
> At which point the deadline is moved ahead and a new task selection is
> done.
> 
> Try and predict the time 'lost' to higher scheduling classes. Since
> this is an estimate, the timer can be both early or late. In case it
> is early task_tick_fair() will take the !need_resched() path and
> restarts the timer.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> ---

...

> @@ -6735,21 +6724,39 @@ static inline void sched_fair_update_sto
>  static void hrtick_start_fair(struct rq *rq, struct task_struct *p)
>  {
>  	struct sched_entity *se = &p->se;
> +	unsigned long scale = 1024;
> +	unsigned long util = 0;
> +	u64 vdelta;
> +	u64 delta;
>  
>  	WARN_ON_ONCE(task_rq(p) != rq);
>  
> -	if (rq->cfs.h_nr_queued > 1) {
> -		u64 ran = se->sum_exec_runtime - se->prev_sum_exec_runtime;
> -		u64 slice = se->slice;
> -		s64 delta = slice - ran;
> -
> -		if (delta < 0) {
> -			if (task_current_donor(rq, p))
> -				resched_curr(rq);
> -			return;
> -		}
> -		hrtick_start(rq, delta);
> +	if (rq->cfs.h_nr_queued <= 1)
> +		return;
> +
> +	/*
> +	 * Compute time until virtual deadline
> +	 */
> +	vdelta = se->deadline - se->vruntime;
> +	if ((s64)vdelta < 0) {
> +		if (task_current_donor(rq, p))
> +			resched_curr(rq);
> +		return;
> +	}
> +	delta = (se->load.weight * vdelta) / NICE_0_LOAD;

Nit.. guess we don't fear overflow since vdelta should be bounded
anyway.

Reviewed-by: Juri Lelli <juri.lelli@...hat.com>

Thanks,
Juri