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:
Thread with prio 30 gets the CPU.
Thread with prio 25 is waiting.
Thread with prio 20 gets the CPU.
Thread with prio 15 is waiting.
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> 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.