Re: OSDL Bug 3770

[Nick Piggin]

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

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