Re: RT task scheduling

[Ingo Molnar <mingo@elte.hu>]

* 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