Date: Thu, 30 Jan 2003 11:23:29 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: James Gritton <gritton@iserver.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: What's the memory footprint of a set of processes? Message-ID: <200301301923.h0UJNT0l089037@apollo.backplane.com> References: <Pine.BSF.4.21.0301291145030.25856-100000@InterJet.elischer.org> <x7k7gnog4m.fsf@guppy.dmz.orem.verio.net> <20030130064448.GA7258@HAL9000.homeunix.com> <200301300719.h0U7JOfI086054@apollo.backplane.com> <20030130091419.GA7776@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301301923.h0UJNT0l089037>