Re: [PATCH] scheduler patch, faster still

yodaiken@chelm.cs.nmt.edu
Mon, 28 Sep 1998 16:43:13 -0600


On Mon, Sep 28, 1998 at 08:26:41PM +0200, Rik van Riel wrote:
> Come on, we've all seen the code. Scanning the longer run
> queue is the _only_ thing that's done when you have a
> long run queue. If you've read the code, you'll reach
> the same conclusion I reached...

Don't. Maybe this tiny difference is caused by cache misses.

> > "Fairly hard" means absolutely nothing at all.
>
> Yes it does. It means that the maximum latency is short.
> Hard means nil latency and soft means we don't care that
> much. The app in question is somewhere in between, but
> closest to real hard RT.

Send glossary with text if you want to use nonstandard definitions.
Still means nothing to me. If it is "real hard RT" then it cannot
abide by Linux's long maximum latency times anyways since the entire
kernel is optimized for average case, not worst case.

> OK, you tell me what's better:
> 1) a simple system with a fair worst-case latency for RT tasks
> 2) a slightly more complex system with excellent worst-case
> latency for RT tasks and a slightly worst latency for non-RT
> tasks

As explained before, it is exceedingly unlikely that the largest cause
of latency in Linux can be found in the scheduler. So we really have

2) a more complex system with slightly better microbenchmark data
using a microbenchmark not shown to indicate anything important or
even to be valid.

> 3) a horribly complex and slow system, which nobody is proposing
> since we can buy NT if we want one of these :)

How do you think that so many smart programmers produced something that
bad? The answer is that they relied on adding features instead of fixing
fundamental problems. 1% here, 4% there, 2% somewhere else -- suddenly the
whole system is gasping for air.

Larry and I and others have seen many OS's that went from "lean and mean"
to "bloated and unmaintainable" in the blink of an eye. That's why we
tend to dismiss even proposals for the smallest increments in code or
complexity unless we see very solid evidence that the change does something
good and nothing bad. That's why we cheer for Linus's "no" -- the only
defense against barbarism and OSFism.

-- 

--------------------------------- Victor Yodaiken Department of Computer Science New Mexico Institute of Mining and Technology Socorro NM 87801 Homepage http://www.cs.nmt.edu/~yodaiken PowerPC Linux page http://linuxppc.cs.nmt.edu Real-Time Page http://rtlinux.org

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