Re: [PATCH v3 01/10] sched/fair: Add EEVDF lag credit primitive for nominated next-buddy

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Wanpeng,

On 6/12/2026 7:03 AM, Wanpeng Li wrote:
> +static void __maybe_unused

I would suggest adding this with the first caller to avoid having to
jump between this and patch 3.

> +eevdf_credit_entity_vlag(struct cfs_rq *cfs_rq, struct sched_entity *se)
> +{
> +	u64 avruntime, credit;
> +	s64 vlag;
> +
> +	/* Callers gate this helper with YIELD_TO_LAG_CREDIT. */
> +	if (cfs_rq->nr_queued < 2)
> +		return;
> +	if (throttled_hierarchy(cfs_rq))
> +		return;
> +	if (WARN_ON_ONCE(!se->on_rq) || se->sched_delayed)
> +		return;
> +
> +	update_curr(cfs_rq);
> +	avruntime = avg_vruntime(cfs_rq);
> +	vlag = entity_lag(cfs_rq, se, avruntime);
> +
> +	/* Already eligible: nothing to do. */
> +	if (vlag >= 0)
> +		return;
> +
> +	credit = (u64)(-vlag);

What is this random credit and how is it fair? My suggestion on the
previous version was simple:

   Task0 -> yield_to -> Task1

- Task0 is eligible and has +ve lag

- Task0 transfers lag to Task1 and makes itself ineligible

- Task1 picks the proportional lag; It may become eligible and get to
  run but there is no guarantee because that is fair.

There is nothing fair about simply making a task eligible just because
someone else decided to call yield_to() on it.

> +
> +	if (cfs_rq->curr == se) {

As mentioned in my reply on the cover, I'm having a hard time
understanding how this can arise when we make sure "p" is a TASK_RUNNING
that is also "!p->on_cpu && p->se.on_rq" while holding p->pi_lock and the
rq_lock.

> +		/* curr is off-tree: in-place shift, carrying any vprot window. */
> +		if (protect_slice(se))
> +			se->vprot -= credit;
> +		se->vruntime -= credit;
> +		se->deadline -= credit;
> +		return;
> +	}
> +
> +	/* Queued entities are left unchanged by this helper path. */
> +}
-- 
Thanks and Regards,
Prateek