lkml.org 
[lkml]   [1999]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Some very thought-provoking ideas about OS architecture.
From
> Batching messages between processes can be good, but what percentage of
the
> time is this practical? In most robust applications you tend to need the
> result of one step before you are sure what the next step is, due to
errors,
> etc. There are obvious exceptions. I could initiate a bunch of writes to
> different places, and look at all the results in one go.

The other obvious exception is when the kernel wants to tell you
something. I.e. instead of using poll or select, you just get the activities on fds
reported via messages. The synchronous IO in Unix is fine for processes that
do one thing at one time, but ugly for serving multiple clients, like web
servers or transaction monitors do.

> The real performance issue isn't one of how communication takes place,
but of
> the total quantity of communication needed. Its just like any human
activity.
> You have one guy on a project, and add a second. What happens? Well, if
each
> can work largely in isolation, with limited need for interaction, you
might
> get nearly twice the output. If they need to communicate a lot you might
get
> less output than the first guy could produce on his own. The same is
true in
> the OS world, or with client/server. You need to minimise the chatting
> (whether its by message passing, system call, or meetings), and maximise
the
> real work. If you ask someone to do something, make sure a concise
request
> produces a substantial reward.

Proceeding a bunch of messages at once can give that reward. You certainly
should make sure that each message itself isn't too fine-grained. If you
want to reduce communication to the max, the best results can be obtained by
sending programs around. Like a web server can tell the OS: whenever an
incomming connection on port 80 is established, read the data until two
consecutive newlines, and give me that data. And the answer would be a small "OSlet",
too: take this filename and content-type, print a formatted header
including file size and last modification date and push the whole file over that TCP
connection. Somewhat like Display Postscript, where the application can
define new rendering functions.

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

Sent through Global Message Exchange - http://www.gmx.net

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

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.184 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site