Date: 30 Jan 2003 09:55:42 -0700 From: James Gritton <gritton@iserver.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: What's the memory footprint of a set of processes? Message-ID: <x7znpi60hd.fsf@guppy.dmz.orem.verio.net> In-Reply-To: Matthew Dillon's message of "Wed, 29 Jan 2003 23:19:24 -0800 (PST)" 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon <dillon@apollo.backplane.com> writes: > You can also theoretically push into shadow VM objects to locate > pages from the parent process that have not yet been COW'd into the > child (in the case of a fork()), noting also that these shadow objects > might be shared with other children of the parent and by the parent > process itself, but under most conditions this information will not > be significant and can be ignored. Actually, that's just the sort of thing I'm looking for. The shared case may be relatively rare, but it tends to be extreme: the processes that use the most memory seem to be the ones that fork the most - database servers, java, etc. The point of this whole thing is an attempt to limit the memory use of a user (instead of a process), but I don't want to penalize such sharing. > Any vnode object is always shared with other processes mapping the > same vnode. Since this information is backed by a file, figuring out > how much 'memory' it represents by any reasonable definition is > guesswork. The resident page count will represent how much of the > vnode is cached, but not how much of the vnode is actually being accessed > by the process. That's OK - resident count is what I'm interested in. That, and the swap approximation (which should suffice) you mentioned for non-vnode objects. - Jamie 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?x7znpi60hd.fsf>