On 28-Mar-98 Chuck Cranor wrote:

>> I've now accounted for the rest.  They seem to emerge from the way the Mach
>> vm system deals with anonymous mappings (meaning mallocs).  Apparently, at
>> some point it wants to start converting them into copy objects, with shadow
>> objects and duplicate pages.  I don't quite understand where or why yet, but
>> I'm assuming it has something to do with the swap pager.
>
> well, it is true shadow and copy objects are paged by the swap pager.
> these objects get created at fork, mmap, or write-fault time.   and 
> the fault routine is constantly looking to collapse the chains to 
> prevent them from getting too long and to prevent "swap memory leak"
> conditions.

Unnamed anonymous mappings, by definition, are isolated at creation.  They have
no reason for any copy-on-write status, nor any connections to any shadow
objects.  Yet they acquire such status and connections, at some point after
being created without them.  Wherever that happens, there can be no valid reason
for it, so there should be nothing to collapse.  It's a bug (whether by design
or otherwise) that generates useless duplicate pages.  The behavior does not
match the description of how the Mach vm is supposed to work (in the CSRG book,
for example).

Interesting, though, that this doesn't happen to the process bss mapping:
Although it acquires a copy status (i.e., "needed" or "done"), it never gets a
pager, even, let alone a shadow object and duplicate pages.

>> I gather it's one of the major points addressed by UVM, so I look forward to
>> seeing how UVM works.
>
> UVM has no object chains, no object collapse problems, and no
> swap memory leaks.  i threw all that complex stuff in the dumpster and
> completely replaced the handling of anonymous memory with something 
> somewhat based on the SunOS4 amap-based anonymous memory system.   

I find the dumpster easy to understand.  My brain feels like spaghetti with
meatballs and cheese.

I do hope UVM is more efficient that this sucker.  I must say, though, I have
yet to personally experience a "modern" OS that actually works right,
especially with respect to vm.  (Of course, I'm cheap, so I've never laid out
substantial bucks for any...)

I also hope that last paragraph doesn't start a flame war.

>> Meanwhile, ddb did reveal something else.  Watching 'systat vmstat' (Cranor's
>> favorite), I see that each new process brings 6 wired pages with it.  Yet
>> looking at the actual vm_map with ddb, I see only 3 wired pages.  Can anyone
>> expain those different numbers?
>
> ah, systat vmstat.
>
> how about this:
>  - 2 pages for the process' U-space:
>       param.h:#define UPAGES      2               /* pages of u-area */
>       param.h:#define USPACE      (UPAGES * NBPG) /* total size of u-area */
>
>    allocated in vm/vm_glue.c in the vm_fork() function:
>
>        /*
>         * Allocate a wired-down (for now) pcb and kernel stack for the process
>         */
>        addr = kmem_alloc_pageable(kernel_map, USPACE);
>        if (addr == 0)
>                panic("vm_fork: no more kernel virtual memory");
>        vm_map_pageable(kernel_map, addr, addr + USPACE, FALSE);
>
>  - 1 page for the process' PDP (page directory page)
>
>    allocated in arch/i386/i386/pmap.c in the pmap_pinit() function:
>
>       pmap->pm_pdir = (pd_entry_t *) kmem_alloc(kernel_map, NBPG);

Right, but where does 'systat vmstat' get its other 3 pages?  (Come to think of
it, if its numbers have everything double, that would explain a lot.)


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 29-Mar-98
Time: 04:06:50

This message was sent by XFMail
----------------------------------