[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions about copy-on-write
From: |
Marcus Brinkmann |
Subject: |
Re: Questions about copy-on-write |
Date: |
Wed, 27 Oct 2004 19:17:44 +0200 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
> Okay, now I'm confused!
From what I understand, your confusion stems from mixing up memory
management and mappings.
Memory management is mostly independent of mapping memory. You can
create containers, grant access to filesystem servers, fill them with
data, and so on, all without mapping them at all.
Mapping is its own operation. The _only_ way in L4 to get a mapping
is to receive a map item in an RPC. There is no other way, not even
for the privileged threads (this is why only the task itself can know
about its mappings, and only if it keeps track of all map items it
receives in all RPCs).
If you page fault, an RPC is sent to your pager, which will normally
be a local thread. That thread looks at the page fault address, and
check its database if there should be a mapping at that address (ie,
if a logical mapping has been installed using mmap, for example). If
there should be some mapping, it can resolve the page fault: If the
page is present in some container, it can simply request a mapping
from physmem. If the page is currently available, it needs to make
the filesystem RPC to get the page, or swap the page in from the
backing store, or allocate more anonymous memory if the mapping is
anonymous and not yet used, or whatever it takes (there will be a
variety of cases).
Now, on the physmem side, if a mapping is requested, some things need
to happen. physmem looks into the container, and if there is a frame
at the requested offset, it can reply the map item for it. But in
case the page is shared copy-on-write, and the task really wants
write-access, first a copy is made to another physical frame, and the
memory becomes unshared (physmem will update the virtual frame info in
the container to point to the new physical frame). Of course other
cases are possible. For example, if the page is only shared with
another soft reference, then simply the soft reference will be dropped
instead of making a copy of the page (effectively unsharing the page,
too).
I hope this helps,
Marcus
- Re: some other memory considerations., (continued)
- Re: some other memory considerations., Espen Skoglund, 2004/10/26
- Re: some other memory considerations., Rian Hunter, 2004/10/26
- Re: some other memory considerations., Marcus Brinkmann, 2004/10/26
- Re: some other memory considerations., Bas Wijnen, 2004/10/26
- Re: some other memory considerations., Marcus Brinkmann, 2004/10/26
Re: some other memory considerations., Marcus Brinkmann, 2004/10/26
- Questions about copy-on-write, Sam Mason, 2004/10/27
- Re: Questions about copy-on-write, Neal H. Walfield, 2004/10/27
- Re: Questions about copy-on-write, Sam Mason, 2004/10/27
- Re: Questions about copy-on-write, Neal H. Walfield, 2004/10/27
- Re: Questions about copy-on-write,
Marcus Brinkmann <=
- Re: Questions about copy-on-write, Sam Mason, 2004/10/27
- Re: Questions about copy-on-write, Bas Wijnen, 2004/10/27
- Re: Questions about copy-on-write, Sam Mason, 2004/10/27
- Re: Questions about copy-on-write, Neal H. Walfield, 2004/10/27
- Re: Questions about copy-on-write, Sam Mason, 2004/10/27
- Re: Questions about copy-on-write, Neal H. Walfield, 2004/10/27
- Re: Questions about copy-on-write, Sam Mason, 2004/10/27
- Re: Questions about copy-on-write, Bas Wijnen, 2004/10/28
Re: Questions about copy-on-write, Bas Wijnen, 2004/10/27
Re: Questions about copy-on-write, Marcus Brinkmann, 2004/10/27