Re: Some very thought-provoking ideas about OS architecture.

Bernd Paysan (bernd.paysan@gmx.de)
Mon, 21 Jun 1999 22:39:42 +0200 (MEST)


On Mon, 21 Jun 1999, Jim Gettys wrote:

> Here's the moral: buffering/batching can work REALLY well, but is BEST done
> at design time, and hard/painful/impossible to retrofit later. It can often
> cause VERY great performance increments (for HTTP/1.1, for example, where
> it turned out to be possible to retrofit to some extent, it can allow
> for a factor of 2-10 performance improvement from our measurments). Whether
> it would make any sense to try to retrofit anything approximating UNIX
> system call semantics onto such a base is far from clear to me at all...

For IO-intensive applications that handle multiple requests from different
clients at once, queued/asynchronous IO (*without* requiring a system call
for every single operation) could work well. IMHO the basic design rule is
to never ever put a synchronous bottleneck at all into your interface -
all synchronous jobs must be done local (no XInternAtoms and that like
;-). This means that one can completely forget about the Unix API as OS
interface - this is far too local stuff.

> So if you want to do this when designing a system, think about it first,
> not later, and think about it hard!

In my experience (and that of a good friend of mine who manages a 100+
controller cluster for over 10 years), sending program snippets around
works best, performance- and bandwidth-reduction-wise. Security however
costs performance, so these things are perhaps better for controlled
environments than for a general purpose OS which has to face a lot of
nasty things.

Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

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