Date:   Thu, 29 Jul 1999 09:11:39 -0600
From:   yodaiken@chelm.cs.nmt.edu
To:     Pavel Machek <pavel@bug.ucw.cz>
Subject: Re: low priority soft RT?

On Thu, Jul 29, 1999 at 12:50:44AM +0200, Pavel Machek wrote:
> > I'm one of those old fashioned people who thinks that a deadlock 
> > with an upper bound is much better than one without.
> 
> Yes, but if you extended your range, you would have "deadlock with
> upperbound of minute" situation, which is very bad, also.

You can't have a free lunch. If you want very relaxed scheduling so that
you don't waste a precious 5% of cpu time on background processes, and
you also want to heavily load the system so there is a strong chance
of conflicting resource requests, and you refuse to use the
obvious user mode solutions,  then you better accept high latencies.

Consider the problem we are trying to solve: it's a ridiculous problem.
Problem:
Too much cpu time spent on non-essential background tasks.
Solution space 1:
Solution1: Don't run them.
Solution2: Kill them when you need to run something else.
Solution3: use a "worthless task" daemon to suspend and restart
           worthless tasks depending on whether or not the system 
           is idle.
Solution4: buy a faster processor or add another node to your beowulf.
Solution5: run NT for a week and then when you go back to Linux the
           5% won't bother you.

etc.
--------------------
Solution space 2:

Add a new scheduling class to the basic system process model and then 
flounder around with all the deadlocks, performance hits, and 
conceptual mess that this addition has caused.


> > 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.
> 
> No. There's currently trick to disable high-priority rt process using
> one normal process grabbing lock and one low-priority rt process
> eating all cpu time. Not good, also.

What's the trick? If I try this program on a uni-processor, the entire
system locks up. No problem on a dual though.

The assumption that every process will make progress in kernel mode
is everywhere in Unix kernels. If you break that assumption, then you
will have a snowballing need for all sorts of junk to keep the 
system running. 



-
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/