Re: [PATCH 3/8] sched/eevdf: Fix HRTICK duration

[Peter Zijlstra <peterz@infradead.org>]

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
>