Re: Kernel support for peer-to-peer protection models...
From: Ivan Godard
Date: Mon Mar 29 2004 - 16:33:51 EST
----- Original Message -----
From: "Davide Libenzi" <davidel@xxxxxxxxxxxxxxx>
To: "Ivan Godard" <igodard@xxxxxxxxxxx>
Cc: "Paul Mackerras" <paulus@xxxxxxxxx>; "Linux Kernel Mailing List"
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
> > 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
> > won't have been in the old data space anyway, so the child references
> > 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
> > 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
> 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.
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/