Messages in this thread | | | Date | Mon, 21 Jun 1999 22:39:42 +0200 (MEST) | From | Bernd Paysan <> | Subject | Re: Some very thought-provoking ideas about OS architecture. |
| |
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/
| |