lkml.org 
[lkml]   [2004]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.070 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site