lkml.org 
[lkml]   [2006]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RT task scheduling

* Darren Hart <dvhltc@us.ibm.com> wrote:

> > -rt14 tree with this bug fixed - does it fix the failures for you?
>
> I ran the test 100 times, no failures! Looks good to me.
>
> # for ((i=0;i<100;i++)); do ./sched_football 4 10 | grep "Final ball position"
> | tee sched_football_ball.log; sleep 1; done
> Final ball position: 0
> ...
> Final ball position: 0

cool!

> Looking at the patch, it looks like the problem was a race on the
> runqueue lock - when we called double_runqueue_lock(a,b) we risked
> dropping the lock on b, giving another CPU opportunity to grab it and
> pull our next task. The API change to double_runqueue_lock() and
> checking the new return code in balance_rt_tasks() is what fixed the
> issue. Is that accurate?

this was one problem, yes. There was another problem too: the code
checked against rq->curr, while it has to consider the 'next' task (the
current task might just be about to leave the CPU at the point we do the
rebalancing). (A third problem was an efficiency issue: the code
indiscriminately pulled all RT tasks it found eligible - while it should
only have pulled ones that preempt the next CPU.)

> I was doing some testing to see why the RT tasks don't appear to be
> evenly distributed across the CPUs (in my earlier post using the
> output of /proc/stat). [...]

could you explain this in a bit more detailed way? [what is the behavior
you observe, and what would be your expectation.]

> [...] I was wondering if the load_balancing code might be interfering
> with the balance_rt_tasks() code. Should the normal load_balancer
> even touch RT tasks in the presence of balance_rt_tasks() ? I'm
> thinking not.

if there is RT overload then running the highest-prio RT tasks trumps
any other consideration - including load_balance(). Also, same-prio
SCHED_FIFO tasks can starve each other indefinitely, so there's not much
the load-balancer can do.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-09 20:36    [W:0.054 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site