Re: Questions about copy-on-write

[Neal H. Walfield]

At Wed, 27 Oct 2004 16:09:04 +0100,
Sam Mason wrote:
> 
> Marcus Brinkmann wrote:
> >The filesystem makes a logical copy of the page from its cache into
> >the container provided by the client, marked copy-on-write.
> 
> I'm fine with everything up to here. . .
> 
> >Then the
> >page can be mapped into the client (read-only).
> 
> Physmem will change the mappings in both tasks so they're read-only
> wont it?

Once a mapping is established, the server can only revoke it.  If a
frame is mark as COW then it will only be mapped read-only unless a
client forces the physical copy.

> >When a write page
> >fault arises, and the client forces a writable mapping, physmem will
> >make the physical copy.  
> 
> Again, the original distinction between the original sharer and
> receiver would have already been lost and the final task still having
> a mapping of the page could be given full read-write permissions
> to the original page.

I don't understand what you mean.  What does the original shared and
receiver refer to?

> >So, COW is implemented lazily.
> 
> In other news: Performance increases have been attributed to the
> recent introduction of lazy COWs to the Hurd . .

I am not sure what you are trying to say here.

> >Note that copying from container to container is usually not a memcpy,
> >but a logical copy of frame references.
> 
> That bit makes sense as well.
> 
> One thing I'm still uncertain about is if a task can (in general)
> modify another tasks mappings.  I would've thought that would be
> a capability limited to only trusted tasks - like physmem, or a
> thread's pager.

The actual mappings are maintained by the task itself: even physmem
has no control over them.  A task will request a mapping from physmem,
set up its receive window to receive it and that is it.  All the
knowledge of mappings between virtual frames and pages is kept in the
task itself.

> Assuming that is the case, the involvement of physmem in this
> procedure is only to ensure that neither task accidentally leaves
> a page mapped as read-write.

When a logical copy is made, the frame is mark read-only and any
read-write mappings are revoked.  This is physmem's job, yes.  As for
the only reason physmem is involved, physmem is integral to this sort
of operation.