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/