Skip site navigation (1)Skip section navigation (2)
Date:      29 Jan 2003 13:28:09 -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:  <x7k7gnog4m.fsf@guppy.dmz.orem.verio.net>
In-Reply-To: Julian Elischer's message of "Wed, 29 Jan 2003 11:45:28 -0800 (PST)"
References:  <Pine.BSF.4.21.0301291145030.25856-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer <julian@elischer.org> writes:

> check out /proc/<PID>/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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x7k7gnog4m.fsf>