l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about copy-on-write


From: Rian Hunter
Subject: Re: Questions about copy-on-write
Date: Wed, 27 Oct 2004 15:14:16 -0400
User-agent: Mozilla Thunderbird 0.8 (Macintosh/20040913)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]