Re: 64-bit virtual adresses and registers

[Jonathan S. Shapiro]

On Mon, 2007-08-06 at 16:52 -0300, Fortes Marcelo wrote:
> A Single address space for a multi server Operating on
> top of a microkernel don looks like a good idea, how
> can i  protect each process server from each other in
> a single adress space ?

The idea behind a single address space operating system (SASOS) is that
all processes agree about the address of every objects. They are not
required to agree about permissions. In real implementations, a context
switch generally means changing the mapping table pointer. This doesn't
change the effective va->pa bindings, but it does change the
permissions.

In real implementations, it is also possible that bindings are built
lazily. An object may be logically mapped at a location without any
hardware mapping existing in the page table of a particular process.

> In fact my question was more related to if any kind of
> cpu registers virtualizations can reduce impact over
> performance due context change between servers.

It doesn't really change anything that I can see in this regard.

> In time,(pardon me by my ignorance)Is Eros/CoyotOS IPC
> message passing sychronous like L4 or Assyinchronous
> like Mach ?

Synchronous. We did discuss asynchronous IPC for a while, but the idea
was much too complicated. It was eventually dropped.

> There is any performance comparison between CoyotOS
> and Modern L4 Implementations,(FIASCO, L4KA)?

Not yet. Coyotos only ran it's first rough IPC three weeks ago.

I do not expect that Coyotos IPC will be as fast as L4 IPC. EROS IPC was
comparable to L4. Experience at the application level led us to make the
Coyotos mechanism more flexible. This has a cost at the kernel level,
but it significantly reduces certain application overheads.

As you look at performance, remember that a fast IPC is not the goal.
The goal is a fast overall system. If you can make a faster IPC without
losing flexibility, that is good. When a proposed design change to the
IPC makes the IPC faster by penalizing the application, you are not
winning anymore.

Also, be skeptical of hot cache performance (which is what all of us
measure). Most processes run long enough to clear the cache, so IPCs are
bimodal; some are hot cache and some are cold cache. The balance depends
on the structure of the OS. As the frequency of cold-cache IPC rises,
the importance of a 10 cycle performance gain in the IPC path shrinks
rapidly -- a single cache miss on modern hardware can be 40 cycles or
more.

Performance is a systemic issue, and IPC is only one part of that issue.


shap