> 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.
yep.
> 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:
you've spelled the problem wrongly, so your `solutions' are not.
> Solution1: Don't run them.
those background tasks are _not_ non-essential (so solution #1 is not;).
they are only non-essential iff other (more important) tasks are running.
these tasks may be so important (or their users think they are;) that
you don't want to spend 5% for the not-so-important tasks.
> Solution2: Kill them when you need to run something else.
not an option in a multi user system where different users
run `idle' tasks and more-important tasks.
> Solution3: use a "worthless task" daemon to suspend and restart
> worthless tasks depending on whether or not the system
> is idle.
using a deamon to watch is not an option if your more-important tasks
have pretty short life time, but are started very frequently (or sleep
relatuvely long time pretty often, e.g. in parallel processing).
the deamon would have to check (poll, ugh;) so often that it wasts
(too much) time itself.
> Solution4: buy a faster processor or add another node to your beowulf.
not an option (and even worse: CPU and disk space requests are like
an ideal gas, they will use up all free/new resources;)
> Solution5: run NT for a week and then when you go back to Linux the
> 5% won't bother you.
the first good one;-)) wish you could tell this our users who complain
about those 5% (it's not me, it's the dear l.user...)
> 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.
yep:(
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
-
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/