[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240806215535.GA36996@noisy.programming.kicks-ass.net>
Date: Tue, 6 Aug 2024 23:55:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Tejun Heo <tj@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, David Vernet <void@...ifault.com>,
Ingo Molnar <mingo@...hat.com>, Alexei Starovoitov <ast@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] sched_ext: Initial pull request for v6.11
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?
Powered by blists - more mailing lists