Re: [PATCH 17/24] sched/fair: Implement delayed dequeue

[K Prateek Nayak]

Hello Mike,

On 11/5/2024 12:16 PM, Mike Galbraith wrote:
> On Tue, 2024-11-05 at 09:52 +0530, K Prateek Nayak wrote:
> > Hello Mike,
>
> Greetings,
>
> > Would checking "p->nr_cpus_allowed > 1" be enough instead of doing a
> > "cpumask_weight(p->cpus_ptr) > 1"?
>
> Yeah (thwap).
>
> > I was thinking, since the task is indeed delayed, there has to be more
> > than one task on the runqueue right since a single task by itself cannot
> > be ineligible and be marked for delayed dequeue?
>
> But they migrate via LB, and idle balance unlocks the rq.
> trace_printk() just verified that they do still both land with
> sched_delayed intact and with nr_running = 1.

Ah! You are right! thank you for clarifying. Since the sharp stick seems
to be working, let me go thrown a bunch of workloads at it and report
back :)

--
Thanks and Regards,
Prateek

> > The only time we
> > encounter a delayed task with "rq->nr_running == 1" is if the other
> > tasks have been fully dequeued and pick_next_task() is in the process of
> > picking off all the delayed task, but since that is done with the rq
> > lock held in schedule(), it is even possible for the
> > "rq->nr_running > 1" to be false here?
>
> I don't see how, the rq being looked at is locked.
>
> 	-Mike