Messages in this thread | | | Date | Mon, 21 Jun 1999 10:25:44 +0000 | From | Steve Underwood <> | Subject | Re: Some very thought-provoking ideas about OS architecture. |
| |
Bernd Paysan wrote:
> Linus Torvalds wrote: > > In short: message passing as the fundamental operation of the OS is just > > an excercise in computer science masturbation. It may feel good, but > > you don't actually get anything DONE. Nobody has ever shown that it > > made sense in the real world. It's basically just much simpler and > > saner to have a function call interface, and for operations that are > > non-local it gets transparently _promoted_ to a message. There's no > > reason why it should be considered to be a message when it starts out. > > This is partly right, and partly wrong. Actually, some light-weight > message passing protocols can be cheaper than function calls. A function > call to a kernel function requires two state transitions (user->kernel > and back), and two context switches; since the kernel wants to massage > different data than the user process, it also has an effect on the > cache.
> Message passing can make this cheaper, if (and only if) your messages > are handled asynchronously. Put a bunch of messages into your shared > memory message buffer (simple *ptr++ = id; *ptr++ = arg; ...), and when > you are done, do the one state transition and context switch, and let > the kernel handle all the requests at once (also simple: next message is > goto *handlers[*ptr++]; Message code does arg = *ptr++;...). The > communication overhead in a good designed active message system can be > below the state transition overhead in a classical OS.
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.
Message passing can work well if its embedded in the processor. The old British GEC4000 minis did this. The ONLY way processes could communicate in those was by message passing, and the microcoded message scheme was as fast as a call. A message to or from an intelligent I/O card was just like a message between CPU processes, too - no need for interrupts.
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.
Steve
- 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/
| |