Re: [PATCH v5 08/14] sched/ext: Add a DL server for sched_ext tasks

[Joel Fernandes <joelagnelf@nvidia.com>]

On Mon, Jun 23, 2025 at 12:11:07PM -1000, Tejun Heo wrote:
> On Fri, Jun 20, 2025 at 04:32:23PM -0400, Joel Fernandes wrote:
> > +static struct task_struct *ext_server_pick_task(struct sched_dl_entity *dl_se,
> > +						void *flags)
> > +{
> > +	struct rq_flags *rf = flags;
> > +
> > +	balance_scx(dl_se->rq, dl_se->rq->curr, rf);
> > +	return pick_task_scx(dl_se->rq, rf);
> > +}
> ...
> > +void ext_server_init(struct rq *rq)
> > +{
> > +	struct sched_dl_entity *dl_se = &rq->ext_server;
> > +
> > +	init_dl_entity(dl_se);
> > +
> > +	dl_server_init(dl_se, rq, ext_server_has_tasks, ext_server_pick_task);
> > +}
> 
> Needing to pass in @rf to ext_server_pick_task() makes sense as SCX always
> needs to balance first. However, I still don't understand why that
> necessitates adding @rf to sched_class->pick_task(). The existing assumption
> is that ->pick_task() cannot release and regrab the rq lock and that's why
> ->balance() exists in the first place. Breaking this can lead to other
> misbehaviors - e.g. if a higher priority class ->pick_task() releases the rq
> lock, a lower one may end up losing a task that its ->balance() saw. This
> can lead to lower priority class's ->pick_task() being called without its
> ->balance() being called which can lead to stalls.
> 
> One thing that confuses me is that all that the patchset needs to do seems
> to be adding @rf to dl_server_pick_f and that seems fine to me. Why is it
> necessary to add @rf to sched_class->pick_task()?

Because ext_server_pick_task is called via DL's pick_task?

In deadline.c, pick_task_dl -> _pick_task_dl -> ext_server_pick_task

This changes the signature of the pick_task_dl function, which in turn
changes the signature of class->pick_task.

How about I pass NULL to pick_task_scx() from ext_server_pick_task(), and
also annotate all functions where rf is unused, by naming the argument as
rf_unused (except for DL), would that make it more clear that the rq lock
should not be arbitrarily dropped just because rf was passed? And perhaps
sprinkling some more code comments.

thanks,

 - Joel