lkml.org 
[lkml]   [2008]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [sched-devel, patch-rfc] rework of "prioritize non-migratable tasks over migratable ones"
>>> 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



\
 
 \ /
  Last update: 2008-06-16 20:47    [W:0.082 / U:0.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site