Re: SCHED_RR/SCHED_FIFO and kernel threads?

["Patrik Hägglund" <patrik.hagglund@bredband.net>]

Steven Rostedt wrote:

>On Fri, 2005-06-17 at 08:38 +0200, Patrik Hägglund wrote:
>  
>
>>Don't you get the problem with priority inversion? I.e., if you have two 
>>processes, P1 and P2, scheduled with SCHED_FIFO, where P1 has higer 
>>priority than P2. Now, if P1 gets blocked and needs some kernel thread 
>>to execute to get unblocked, then P2 is scheduled before the kernel 
>>thread, and can execute without any time limit.
>>    
>>
>
>Yep, that could happen.
>
>  
>
>>That is, you should be much better off if the kernel threads has a 
>>_high_ priority. Then the execution progress can only be blocked by 
>>kernel threads, not by user space threads and processes. Or have I 
>>missed something?
>>    
>>
>
>Still have that problem with priority inversion. Kernel threads share
>date structures with user processes (when they are in kernel mode) and
>that kernel thread that is needed may get blocked on a process that is
>lower in priority than the two mentioned above.
>
>  
>
>>(Besides that, as I see it, SCHED_RR/SCHED_FIFO are scheduling 
>>abstractions on their own, not necessarily  connected to  "low latency " 
>>or "realtime".)
>>    
>>
>
>Only in the vanilla kernel. See Ingo's RT work. It handles priority
>inversion and SCHED_RR/SCHED_FIFO are actually connected to "low
>latency" and "realtime".
>
>http://people.redhat.com/mingo/realtime-preempt/
>
>-- Steve
>
>
>-
>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/
>
>  
>
Thanks for the pointer to Ingo's work. I will have a look.

Regarding my last comment: What I was trying to say was that I thought 
there are _basic_ aspects to consider (i.e. my original problem with 
kernel starvation) when implementing SCHED_RR/SCHED_FIFO _before_ you 
consider how to implement them in a "low latency" or "realtime" context.

/Patrik Hägglund