Linux-kernel mailing list archive 1999-25,: Re: Some very thought-provoking ideas about OS architecture.

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

Steve Underwood (steveu@netpage.com.hk)
Mon, 21 Jun 1999 10:25:44 +0000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alan Cox: "Re: [patch] `cp /dev/zero /tmp' (patch against 2.2.9)"
- Previous message: Alan Cox: "Re: I discussed reading directories as files with jra, Stallman,"
- Maybe in reply to: Eric S. Raymond: "Some very thought-provoking ideas about OS architecture."
- Next in thread: shapj@us.ibm.com: "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/

- Next message: Alan Cox: "Re: [patch] `cp /dev/zero /tmp' (patch against 2.2.9)"
- Previous message: Alan Cox: "Re: I discussed reading directories as files with jra, Stallman,"
- Maybe in reply to: Eric S. Raymond: "Some very thought-provoking ideas about OS architecture."
- Next in thread: shapj@us.ibm.com: "Re: Some very thought-provoking ideas about OS architecture."