Messages in this thread | | | Date | Wed, 28 Jul 1999 07:09:32 +1000 | From | Richard Gooch <> | Subject | Re: low priority soft RT? |
| |
yodaiken@chelm.cs.nmt.edu writes: > On Tue, Jul 27, 1999 at 04:25:21PM +0200, Rik van Riel wrote: > > Sure. If you have a bunch of normal, interactive and niced > > processes, then a high-priority process can wait for over a > > second before a lock (held by a niced process) is released > > and the high-priority process can continue. > > > > Now, if we would follow Linus' idea and extend the range > > of niced processes, that time span could increase to 10 or > > even more seconds, effectively producing the same kind of > > 'deadlock' that SCHED_IDLE can produce -- only with an upper > > bound to it... > > I'm one of those old fashioned people who thinks that a deadlock > with an upper bound is much better than one without. > > > Then throw in SCHED_RR or SCHED_FIFO processes and you're > > gone. > > But SCHED_RR is a problem on its own, is it not? > > setsched(SCHED_RR) > while(i < 100 ){ > g = g+1; > /* oops, I forgot to increment i*/ > } > > And inetd never runs again.
I think what Rik means is that a RT process can try to get a lock (i.e. directory semaphore) which is held by a SCHED_OTHER process. The SCHED_OTHER process stops getting CPU time, and thus cannot release the lock. Hence we have deadlock. Of course, a RT process hitting the FS is somewhat questionable, but in some cases is legitimate (i.e. you have two RT processes, the high priority one queues data to the low priority one which hits the FS), provided you know what you are doing.
SCHED_IDLE presents the same problem: SCHED_IDLE process holds a lock, which locks out a SCHED_OTHER process. Again, permanently.
So SCHED_IDLE shouldn't be lambasted for making a deadlock possible, because SCHED_OTHER (in the presence of RT processes) can do the same. Which is why I support moving !SCHED_OTHER processes to SCHED_OTHER when they call schedule(), and moving them back when schedule() returns.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |