Re: [PATCH] limits on SCHED_FIFO tasks

[rm <async@cc.gatech.edu>]

On Tue, Mar 18, 2003 at 05:12:45PM -0800, george anzinger 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.

some of the code out there already uses a watchdog process. there are
a couple of issues with it. 

first, it's difficult to figure out when another process is behaving
badly. and if another process is behaving badly, the only choice you
have is to kill it. secondly, what happens if the watch dog process
dies or the bug is in that process itself? i once accidently killed
the thread serving as the watchdog and then hung the system trying to
bring down the SCHED_FIFO program afterward.

the glib answer is, 'don't do stupid things'. unfortunately, people do
stupid things, and the system shouldn't be vulnerable to them to the
extent possible. it's like saying, 'preemptive multitasking isn't
necessary because cooperative multitasking works fine and offers lower
overhead...just don't run stupid code with bugs in it'.

it seems like this is more easily and more completely solved by
allowing limitations to be placed on what a sched_fifo task can do, in
the same way that the kernel allows you to put limits on users and
programs.

i'm not arguing against other people using SCHED_FIFO to lockup their
boxes, just that there needs to be something in between running as
SCHED_OTHER, and running with absolutely no limits as SCHED_FIFO.

		thanks, 
		 rob

----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async@cc.gatech.edu