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

[Davide Libenzi <davidel@xmailserver.org>]

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?



- Davide