Re: Questions about copy-on-write

[Rian Hunter]

Sam Mason wrote:

> > 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.
>  
yes definitely, physmem would have to know who has the page COW and who 
really owns the page, otherwise how would it know who to make the 
physical copy for on a fault. Or if the mapper suddenly dies, physmem 
knows to just give the page to the client, but if the client suddenly 
dies the physmem doesn't really have to do anything with that page to 
the mapper (except normal kill procedures).

> > > 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. . .
>  
lazy copy-on-write isn't necessarily a perfomance increase.

> > 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.
>  
i think the general understanding has currently bin that 
mapping/unmapping will be a privilegded operation. ie. only hurd servers 
should be doing, or most precisely mostly physmem. untrusted tasks won't 
really be unmapping/mapping, they will be using containers and closing 
containers, and dying. physmem will take care of the actual business of 
mapping and copying and etc.

physmem will be predictably mature into being a very intelligent and 
thoughtful program, yet not very complicated as it won't (ideally) 
contain any policy on memory. it will only serve as the do-boy for 
memory, or at least that's the picture i'm seeing painted. but not just 
any do-boy, a muscular, well-trained, firm and obedient do-boy. if it 
needs to know something to accurately perform a certain task (like 
distinguishing which task is the provider of a copy-on-write page) then 
it will certainly be given this knowledge.
-rian