Re: low priority soft RT?

Richard Gooch (rgooch@atnf.csiro.au)
Fri, 30 Jul 1999 06:34:01 +1000

yodaiken@chelm.cs.nmt.edu writes:
> 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.

;-)

I thought about how to implement such a daemon, bu quickly started
seeing the difficulties. For example, dealing with forking...

> 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.
[...]
> 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.

So promote and demote them as you schedule() or enter/leave the
kernel.

Nevertheless, if you've got a way of solving the problems with
solution space 1, I'd like to see that pursued. If we can do it nicely
in user space then I'm all for it.

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/