RE: rfork() and copy on write

But it would also be copy-on-read  (copy across the net, that is) as
well as copy-on-write (actually if you were overwriting completely you
wouldn't have to copy at all).  Oh, well. Just being silly.  Aneesh is
correct that we could begin execution on the new node for rfork and
migrate much more quickly if we could demand pull over the pages we
needed as we needed them instead of stopping execution while all the
dirty pages are copied (clean pages are re-paged from the executable). 

-----Original Message-----
From: Aneesh Kumar [mailto:[email protected]] 
Sent: Tuesday, April 18, 2006 7:59 PM
To: Walker, Bruce J (HP-Labs)
Cc: Jack de Valpine; [email protected]
Subject: Re: [SSI-users] rfork() and copy on write

On 4/18/06, Walker, Bruce J (HP-Labs) <[email protected]> wrote:
> Yes and no.  The child has the same image as the parent (as in fork) 
> and any changes made by either don't effect the other (the copy of 
> write semantic).  So the semantics of rfork at identical to fork.  
> However, the implementation is to copy all the pages to the new node 
> so the parent and child are not physically sharing the same page.
>
>

There is one optimization that would really help the performance but
compromise the availability. This is to make sure pages are pulled from
origin node only when needed. Similar to copy on write. But the problem
is that in that case we cannot afford to lose the origin node even after
process got migrated to a different node.

-aneesh


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642