Re: [PATCH sched_ext/for-7.1] sched_ext: Documentation: Add missing calls to quiescent(), runnable()

[Andrea Righi]

On Thu, Apr 09, 2026 at 10:46:09AM +0100, Christian Loehle wrote:
> On 4/9/26 09:46, Kuba Piecuch wrote:
> > On Wed Apr 8, 2026 at 2:54 PM UTC, Andrea Righi wrote:
> > ...
> >>>
> >>> Another inaccuracy not related to direct dispatch: property changes can occur
> >>> while a task is running, while the psedocode only allows for property changes
> >>> while a task is queued.
> >>
> >> Sure... but again, modelling all the possible scenarios would make the
> >> pseudocode completely unreadable.
> > 
> > I'm not arguing we should cover all scenarios.
> > 
> > I'm ok with omitting scenarios whose existence depends on a configuration flag
> > or presence/absence of a callback, because:
> > 
> > a) Using the right configuration, one can actually write a scheduler where the
> >    pseudocode is an accurate representation of the task lifecycle;
> > 
> > b) The assumptions about the configuration can be clearly stated next to the
> >    pseudocode.
> > 
> > I'm less ok with omitting specific scenarios that can't be simply "turned off"
> > because they are triggered by the scheduled tasks themselves. A task's property
> > being changed while it's running is one example of such a scenario -- one can't
> > just prevent it from happening by setting a configuration flag, and sched_ext
> > schedulers implementing dequeue/quiescent/runnable/enqueue should be aware of
> > it.
> > 
> > What I especially don't like is giving the reader a partial picture that looks
> > like a complete one, as is the case with property changes here. We're letting
> > the reader know that it can happen, but the pseudocode makes it look like it
> > can only happen while a task is queued and not while it's running, giving the
> > reader a false impression that they can assume property changes apply only to
> > queued tasks.
> 
> 
> Agreed FWIW, I've implemented a few schedulers that need to track state transitions
> 100% accurately and it was painful to get it 100% right.
> I think it's either this or we add a sample BPF scheduler that actually does
> track/validate all possible transitions per-task accurately to illustrate. (Maybe a
> selftest?)

One thing doesn't exclude the other, we can have an example scheduler that
implements 100% accurate state tracking (the dequeue kselftest is probably
already a valid example of that) and this slightly inaccurate high-level
overview of the task lifecycle workflow.

-Andrea