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