Re: [GIT PULL] sched_ext: Initial pull request for v6.11

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Aug 06, 2024 at 11:34:19AM -1000, Tejun Heo wrote:

> > > +static struct task_struct *pick_task_scx(struct rq *rq)
> > > +{
> > > +	struct task_struct *curr = rq->curr;
> > > +	struct task_struct *first = first_local_task(rq);
> > > +
> > > +	if (curr->scx.flags & SCX_TASK_QUEUED) {
> > > +		/* is curr the only runnable task? */
> > > +		if (!first)
> > > +			return curr;
> > > +
> > > +		/*
> > > +		 * Does curr trump first? We can always go by core_sched_at for
> > > +		 * this comparison as it represents global FIFO ordering when
> > > +		 * the default core-sched ordering is used and local-DSQ FIFO
> > > +		 * ordering otherwise.
> > > +		 *
> > > +		 * We can have a task with an earlier timestamp on the DSQ. For
> > > +		 * example, when a current task is preempted by a sibling
> > > +		 * picking a different cookie, the task would be requeued at the
> > > +		 * head of the local DSQ with an earlier timestamp than the
> > > +		 * core-sched picked next task. Besides, the BPF scheduler may
> > > +		 * dispatch any tasks to the local DSQ anytime.
> > > +		 */
> > > +		if (curr->scx.slice && time_before64(curr->scx.core_sched_at,
> > > +						     first->scx.core_sched_at))
> > > +			return curr;
> > > +	}
> > 
> > And the above condition seems a little core_sched specific. Is that
> > suitable for the primary pick function?
> 
> Would there be any distinction between pick_task() being called for regular
> and core sched paths?

There currently is not -- but if you need that, we can definitely add a
boolean argument or something. But I think it would be good if a policy
can inherently know if curr is the better pick.

ISTR you having two queue types, one FIFO and one vtime ordered, for
both I think it should be possible to determine order, right?