Re: [PATCH] sched/core: fix pick_next_task 'max' tracking

From: Peter Zijlstra
Date: Tue Aug 24 2021 - 04:55:47 EST


On Mon, Aug 23, 2021 at 04:24:26PM -0700, Josh Don wrote:
> Hi Peter,
>
> On Mon, Aug 23, 2021 at 4:17 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> [snip]
> > + for_each_cpu(i, smt_mask) {
> > + rq_i = cpu_rq(i);
> > + p = rq_i->core_temp;
> >
> > - /*
> > - * If this sibling doesn't yet have a suitable task to
> > - * run; ask for the most eligible task, given the
> > - * highest priority task already selected for this
> > - * core.
> > - */
> > - p = pick_task(rq_i, class, max, fi_before);
> > + if (!cookie_equals(p, cookie)) {
> > + p = NULL;
> > + if (cookie)
> > + p = sched_core_find(rq_i, cookie);
>
> In the case that 'max' has a zero cookie, shouldn't we search for a
> match on this cpu if the original class pick ('p') had a non-zero
> cookie? We don't enqueue tasks with zero cookie in the core_tree, so I
> forget if there was some other reasoning here.

IIRC we don't keep 0-cookies in the tree. Lemme check.

Yeah, see sched_core_enqueue(), they bail for 0-cookie.

This is indeed sub-optimal, but also having the 0-cookie tasks in the
tree has other issues IIRC.