Re: [PATCH v2 0/6] sched/fair: Manage lag and run to parity with different slices
From: Peter Zijlstra
Date: Tue Jul 08 2025 - 14:44:55 EST
On Mon, Jul 07, 2025 at 05:49:05PM +0200, Vincent Guittot wrote:
> > > Patch 5 fixes the case of tasks not being eligible at wakeup or after
> > > migrating but with a shorter slice. We need to update the duration of the
> > > protection to not exceed the lag.
> >
> > This has issues with non-determinism; specifically,
> > update_protected_slice() will use the current ->vruntime, and as such
> > can unduly push forward the protection window.
>
> se->vprot = min_vruntime(se->vprot, (se->vruntime +
> calc_delta_fair(quantum, se)));
>
> the min_vruntime (previously min) with current vprot (previously vlag)
> should prevent pushing forward the protection. We can only reduce
> further the vlag but never increase it
Fair enough.
> > +/*
> > + * Should we still run @se? It is allowed to run until either se->deadline or
> > + * until se->vprot + min_vslice, whichever comes first.
> > + */
> > +static inline bool protect_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > {
> > + u64 min_vslice, deadline = se->deadline;
> > + u64 min_slice = cfs_rq_min_slice(cfs_rq);
> >
> > + if (min_slice != se->slice) {
> > + min_vslice = calc_delta_fair(min_slice, se);
> > + deadline = min_vruntime(se->deadline, se->vprot + min_vslice);
>
> I didn't go into that direction because protect_slice() is call far
> more often than set_protect_slice() or update_protect_slice()
Right.
> > + }
> >
> > + WARN_ON_ONCE(!se->on_rq);
> > +
> > + return ((s64)(deadline - se->vruntime) > 0);
> > }
Anyway, I see you posted a new version. Let me go have a look.