Messages in this thread | | | Date | Tue, 21 Dec 2004 22:09:50 +1100 | From | Nick Piggin <> | Subject | Re: OSDL Bug 3770 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |