:I think the original poster wanted to know the real memory use of
:a set of processes, taking sharing into account.  I don't see how
:your approach could do that.  Even if you knew the structure of
:the shadow chain, you would have to know specifically which pages
:had been COWed, no?
:
:I thought counting vm_page structures would be the way to go...
:I really want to find the time to learn all this stuff better.
:I still don't know the difference between COW and NEEDS_COPY,
:or why the pageout daemon seems to be biased against shared
:pages, or a lot of things about pv_entry structures.

    It's not possible to get a wholely accurate count no matter what
    you do.  For example, to truely know whether a process is using
    a page you have to run through the process's page table (PMAP),
    access the vm_page, then locate where in the shadow chain the VM object
    the vm_page belongs to resides.  But since hardware page tables are
    throw-away, the system could very well have thrown away whole page
    tables so this method is no more accurate then any other.

    Shadow VM objects are optimized on the fly.  When a shadow object 
    representing data shared by multiple processes is completely covered
    (due to COW faults) the system will delete the shadow object.  So you
    can get a pretty good idea in regards to shared pages simply by 
    noting the existance of the shadow object and the number of resident
    or swap pages residing in that object.

    MAP_ENTRY_NEEDS_COPY is a vm_map_entry optimization that allows
    two vm_map_entry's (for two different processes) to share the same
    vm_object even though they are copy-on-write.  This allows us to
    defer allocating new VM objects (defer creating the shadow structures)
    for anonymous area of memory when a process fork()s, until an actual
    copy-on-write occurs.  Being able to defer this allocation greatly
    reduces the time and memory required to fork() and gives us a flatter,
    more easily optimized VM object structure.

                                        -Matt
                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to