From owner-freebsd-hackers Wed Jan 29 12:28:18 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 C1FFB37B401 for ; Wed, 29 Jan 2003 12:28:16 -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 AFC7543F3F for ; Wed, 29 Jan 2003 12:28:15 -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 24B873BF121 for ; Wed, 29 Jan 2003 13:28:10 -0700 (MST) Received: from guppy.dmz.orem.verio.net by guppy.dmz.orem.verio.net; Wed, 29 Jan 2003 13:28:09 -0700 (MST) Received: (from gritton@localhost) by guppy.dmz.orem.verio.net (8.12.3/8.12.3/Submit) id h0TKS9Vu023133; Wed, 29 Jan 2003 13:28:09 -0700 (MST) To: freebsd-hackers@FreeBSD.ORG Subject: Re: What's the memory footprint of a set of processes? References: From: James Gritton Date: 29 Jan 2003 13:28:09 -0700 In-Reply-To: Julian Elischer's message of "Wed, 29 Jan 2003 11:45:28 -0800 (PST)" Message-ID: Lines: 46 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 Julian Elischer writes: > check out /proc//map for a really detailed map of the process. That looks good for a single process, suffers from the problem I'm having. For example, if I run a program that simply mallocs a chumk of memory and reads through it (to map it all in), it's pretty easy to identify the affected object: guppy% cat /proc/23072/map 0x8048000 0x8049000 1 0 0xcdd610c0 r-x 1 0 0x0 COW NC vnode 0x8049000 0x804a000 1 0 0xce619060 rw- 2 0 0x2180 NCOW NNC default 0x804a000 0xc04b000 16385 0 0xce619060 rwx 2 0 0x2180 NCOW NNC default ... But after sleeping for a bit, the program then forks, and I have two processes sharing the same memory. I hope to see something that reflects this, but: guppy% cat /proc/23072/map 0x8048000 0x8049000 1 0 0xcdd610c0 r-x 2 0 0x0 COW NC vnode 0x8049000 0x804a000 1 0 0xcdc84360 rw- 2 0 0x180 COW NC default 0x804a000 0xc04b000 16385 0 0xce619060 rwx 2 0 0x180 COW NC default ... guppy% cat /proc/23074/map 0x8048000 0x8049000 1 0 0xcdd610c0 r-x 2 0 0x0 COW NC vnode 0x8049000 0x804a000 1 0 0xcdc84360 rw- 2 0 0x180 COW NC default 0x804a000 0xc04b000 16385 0 0xce619060 rwx 2 0 0x180 COW NC default ... The object's ref_count hasn't changed, which is what I meant about seeing reference counts in the kernel that were apparently not counting what I'm looking for. I did see a ref_count increase on the first object (presumably the text image), but nothing on the allocated memory. It seems the object level isn't fine enough, but the deeper I go into the VM code, the more confused I become. In this forked process example, what happens when I alter a few COW pages in the currently-shared object? Apparently a shadow object is created, but it claims to be the same size as the original object. True, but I know it's not actually using that many pages, since most of them are still validly shared. System usage numbers tell me this is true, but I can't find what in the process or object data structures reflect this fact. - Jamie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message