linux-kernel - Re: [PATCH 3/8] 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] [day] [month] [year] [list]

Message-ID: <20251128083220.GB3245006@noisy.programming.kicks-ass.net>
Date: Fri, 28 Nov 2025 09:32:20 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: tglx@...utronix.de, arnd@...db.de, anna-maria@...utronix.de,
	frederic@...nel.org, luto@...nel.org, mingo@...hat.com,
	juri.lelli@...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 3/8] sched/eevdf: Fix HRTICK duration

On Fri, Sep 19, 2025 at 09:04:02PM +0530, K Prateek Nayak wrote:
> Hello Peter,
> 
> On 9/18/2025 1:22 PM, Peter Zijlstra wrote:
> > +	/*
> > +	 * Compute time until virtual deadline
> > +	 */
> > +	vdelta = se->deadline - se->vruntime;
> > +	if ((s64)vdelta < 0) {
> > +		if (task_current_donor(rq, p))
> > +			resched_curr(rq);
> 
> Why the task_current_donor() check? If the scheduling context has run
> out of gas, shouldn't we reschedule curr even if we were proxied?

task_current_donor() is the current scheduling context, right? So we've
just determined that vruntime is ahead of deadline, which means we
should reschedule now.

> > +		return;
> > +	}
> > +	delta = (se->load.weight * vdelta) / NICE_0_LOAD;
> > +
> > +	/*
> > +	 * Correct for instantaneous load of other classes.
> > +	 */
> > +	util += cpu_util_dl(rq);
> > +	util += cpu_util_rt(rq);
> > +	util += cpu_util_irq(rq);
> > +	if (util && util < 1024) {
> > +		scale *= 1024;
> > +		scale /= (1024 - util);
> >  	}
> 
> Could it be possible that we arrive here from the dl_server's pick and
> end up inflating the HRTICK duration despite having an uninterrupted
> period for fair tasks ahead?

Yes, but since this is all approximation anyway, how many correction
terms do we want to stack on top ? :-)

> > +	hrtick_start(rq, (scale * delta) / 1024);
> >  }
> >  
> >  /*
> -- 
> Thanks and Regards,
> Prateek
>