Re: OSDL Bug 3770

[Nick Piggin <piggin@cyberone.com.au>]

Loic Domaigne wrote:

>Hello Nick,
>
>Thanks for your reply! 
> 
>L = Loic 
>N = Nick 
>
>N> lkml: We're discussing the fact that on SMP machines, our realtime 
>N> scheduling policies are per-CPU only. This caused a problem where a 
>N> high priority task on one CPU caused all lower priority tasks on that 
>N> CPU to be starved, while tasks on another CPU with the same low 
>N> priority were able to run.
>
>That summary should readily motivate you to make a patch ;-) 
>
>But thing are a bit worse actually. It is easily to build an example 
>where a lower priority thread is executing while a higer priority thread
>is waiting. For instance, something like: 
>
>CPU0:
>Thread with prio 30 gets the CPU.
>Thread with prio 25 is waiting.
>
>CPU1:
>Thread with prio 20 gets the CPU.
>Thread with prio 15 is waiting.
>
>

Yep.


[snip]

>L> The reason is extremely simple: the application *CANNOT* necessarily 
>L> known that it gets stuck behind a higher-priority thread (though it 
>L> could had run on another CPU if the scheduler had decided otherwise). 
>L> That's *NOT* doable to program in a deterministic fashion in such 
>L> "realtime"-environement
>N>
>N>
>N> You could use CPU binding. I'd argue that this may be nearly a
>N> requirement for any realtime system of significant complexity on 
>N> an SMP system.
>
>Agree. Real-world system will likely want to have a control on which 
>CPU the threads runs on SMP machine. 
>
>Does Linux tolerate hard CPU binding? By hard CPU binding, I mean 
>that the application tells the scheduler "I want to run there", 
>and the scheduler schedules the thread(s) "there" regardless if it 
>makes sense or not ( The decision is left to the application). 
>
>With such hard CPU binding, it seems to me that our "unfortunate 
>behavior" isn't problematic anymore. Because the application can gain 
>control again over the scheduler (so to speak). 
>
>On the other hand, if the scheduler might ignore the CPU binding 
>(thus, not hard binding, but rather CPU affinity), then I am afraid 
>that the issue might remain problematic.  
>
>

Yes, it does support hard CPU binding - sched_setaffinity

[snip interesting dialogue]

Thanks for your detailed comments, they were interesting.

I hope that the fact we have hard CPU binding is a sufficient
solution to the problem.

Thanks
Nick