Re: OSDL Bug 3770

From: Nick Piggin
Date: Tue Dec 21 2004 - 06:11:45 EST

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:

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.

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at