Re: Kernel support for peer-to-peer protection models...

[Ivan Godard]

----- Original Message ----- 
From: "Davide Libenzi" <davidel@xxxxxxxxxxxxxxx>
To: "Ivan Godard" <igodard@xxxxxxxxxxx>
Cc: "Paul Mackerras" <paulus@xxxxxxxxx>; "Linux Kernel Mailing List"
<linux-kernel@xxxxxxxxxxxxxxx>
Sent: Monday, March 29, 2004 10:45 AM
Subject: Re: Kernel support for peer-to-peer protection models...


> On Sun, 28 Mar 2004, Ivan Godard wrote:
>
> > Ah! you wanted to know about exec, not fork. A true fork() is pretty
rare
> > these days anyway. Still, the answer is pretty much the same: the fork()
> > gets you a new data space, retaining the old code space, and the exec()
> > finds (or creates) the code space that cmd's code is in and switches the
> > active code space to that space. Heritable data, such as file
descriptors,
> > won't have been in the old data space anyway, so the child references
them
> > through syscalls just as in a conventional.
> >
> > Perhaps I'm missing your question here, but in general we see no problem
> > with fork/exec in our model - it's one of the least changed things. You
> > always get a new address space on a conventional, and you also do with a
> > Mill; the only difference is that you don't have to shoot down the cache
or
> > TLB, so a fork/exec should be quite a bit faster.
>
> No, sorry. Lossy email compression (sometimes being concise is a virtue
> but I usually fall way too far). Reading thru previous messages seems
> confusing to me. On one side you say that fork() uses a std COW, on the
> other side you say that the unified virtual address space combined with
> virtually tagged cache let you avoid cache flushes. As soon as you COW,
> you have one virtual address that refer to two different physical
addresses.
> Does the virtual address have extra tag bits to identify the task?

No, but it has a mechanism (unfortunately I can't explain yet  how it works)
which amount to the same thing. In fact, the hardware can distinguish
between the case where a particular address in the child is supposed to
refer to the child, and the case where it's supposed to refer back into the
parent. This is a novel feature that is not supportd by the conventional
model. We expect to expose it through an API. For example a server can spawn
worker processes such that each worker has its own space (and is protected
from other workers) but can communicate with the server via data structures
in the server, where the new worker COW comes up with the back-references
already created. This gives the convenience of thread-workers with the
protection of process-workers using a mmap communication region, but without
the overhead of creating the region.

Ivan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/