Re: [sched-devel, patch-rfc] rework of "prioritize non-migratable tasks over migratable ones"

["Gregory Haskins" <ghaskins@novell.com>]

>>> On Mon, Jun 16, 2008 at  1:59 PM, in message
<b647ffbd0806161059q7048ea40id0f4235ab19d6ca0@mail.gmail.com>, "Dmitry
Adamushko" <dmitry.adamushko@gmail.com> wrote: 

[snip]

> that's why I called the current (mine is similar)
> definition/implementation of "bound" (or "non-migratable" in my terms
> above) sub-optimal.
> 
> hope it's clear now (and none of the important details are escaping me) :-)

Indeed.  I understand your point now.  To summarize: nr_cpus_allowed is not sufficient to determine if this "load-balancing" operation should be attempted.  Rather, we need to consider whether task_4->cpus_allowed results in no preemption when looking at [1,3], but task_3->cpus_allowed shows the cpu_4 could be preempted.

This problem is easily and efficiently solvable,  and I think your "HEAD" approach is better than my xqueue/squeue idea.  Now the question remains: "Is the whole concept worth it, or should we drop it?"

If we wanted to fix this, we could run both current and the wakee into cpupri for the case where wakee->prio == rq->highest_prio (*).  If wakee comes back with 0 targets but rq->HEAD (*) comes back with potential targets, then wakee should insert to the HEAD and preempt.  Otherwise, tail-insert as always.  (We will still race against the potential targets becoming unavailable to accept current, but as I indicated in the last message, this is unavoidable).

(*) Note that its important to use rq->highest_prio/HEAD and not rq->current so that we don't look at the state of the queue while in the process of rescheduling

Thanks for clarifying, Dmitry.  I think you are right.

Regards,
-Greg