Re: [PATCH] limits on SCHED_FIFO tasks

[george anzinger]

Andrew Morton wrote:
> george anzinger <[e-mail]> wrote:
> 
>>If the issue is regaining control after some RT task goes into a loop, 
>>the way this is usually done is to keep a session around with a higher 
>>priority.  Using this concept, one might provide tools that, from 
>>userland, insure that such a session exists prior to launching the 
>>"suspect" code.  I fail to see the need for this sort of code in the 
>>kernel.
> 
> 
> That works, until your shell calls ext3_mark_inode_dirty(), which blocks on
> kjournald activity.  kjournald is SCHED_OTHER, and never runs...
> 
That is classic priority inversion.  It would be "nice" to find a fix 
for that :)  I think that the proposed action should not be triggered 
until there is some "notice" that something is wrong.  I suppose it 
could be a watchdog timer of some sort.  Still, if the priority 
inversion issue were solved, all the rest could be done in user land.

> 
> 

-- 
George Anzinger   [e-mail]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml