Re: Questions about copy-on-write

[Sam Mason]

Neal H. Walfield wrote:
>Sam Mason wrote:
>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.

Which it would do my writing something to a page or doing some IPC?

>> 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?

In the example of a file system sharing part of a file with an
application, the sharer would be the file system and the reciever
would be the task asking for the data from the file.  I was trying to
ask that after the operation has completed would there be any
difference (from physmem's viewpoint) between the two tasks.

>> 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.

It was supposed to be humorous! ah well. . .

>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.

Okay, now I'm confused!  What you've just described is how I would
expect it to work.  But the reason for the existance of containers
seems to be that that once a task shares a page with another task,
that mapping can be revoked at any time.  I thought it was a bit
strange, but that seemed to be the justification of the containers.
The only task we trust not to revoke these mapping is physmem.

I assume I've made some misunderstandings somewhere along the
line then.

>> 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.

I think that when I understand what's going on above this should make
sense.