From owner-freebsd-hackers Thu Jan 30 8:55:47 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD04137B401 for ; Thu, 30 Jan 2003 08:55:45 -0800 (PST) Received: from gatekeeper.oremut01.us.wh.verio.net (gatekeeper.oremut01.us.wh.verio.net [198.65.168.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A93A43F75 for ; Thu, 30 Jan 2003 08:55:45 -0800 (PST) (envelope-from gritton@iserver.com) Received: from guppy.dmz.orem.verio.net (guppy.dmz.orem.verio.net [10.1.1.55]) by gatekeeper.oremut01.us.wh.verio.net (Postfix) with ESMTP id E55193BF11C for ; Thu, 30 Jan 2003 09:55:43 -0700 (MST) Received: from guppy.dmz.orem.verio.net by guppy.dmz.orem.verio.net; Thu, 30 Jan 2003 09:55:43 -0700 (MST) Received: (from gritton@localhost) by guppy.dmz.orem.verio.net (8.12.3/8.12.3/Submit) id h0UGthYh027119; Thu, 30 Jan 2003 09:55:43 -0700 (MST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: What's the memory footprint of a set of processes? References: <20030130064448.GA7258@HAL9000.homeunix.com> <200301300719.h0U7JOfI086054@apollo.backplane.com> From: James Gritton Date: 30 Jan 2003 09:55:42 -0700 In-Reply-To: Matthew Dillon's message of "Wed, 29 Jan 2003 23:19:24 -0800 (PST)" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon 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