Date: Mon, 22 Jan 2001 21:13:09 +0100 From: Cliff Sarginson <cliff@raggedclown.net> To: Mike Meyer <mwm@mired.org> Cc: Gustavo Vieira Goncalves Coelho Rios <gustavo@ifour.com.br>, questions@FreeBSD.ORG Subject: Re: small program eats lot of memory Message-ID: <20010122211309.A958@raggedclown.net> In-Reply-To: <14956.14518.590300.22504@guru.mired.org>; from mwm@mired.org on Mon, Jan 22, 2001 at 07:42:14AM -0600 References: <E14KedS-000NHH-00@post.mail.nl.demon.net> <14956.14518.590300.22504@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 22, 2001 at 07:42:14AM -0600, Mike Meyer wrote:
> Cliff Sarginson <cliff@raggedclown.net> types:
> > > Cliff Sarginson <cliff@raggedclown.net> types:
> > > > > Cliff Sarginson <cliff@raggedclown.net> types:
> > > > > > On Sunday 21 January 2001 16:48, Mike Meyer wrote:
> > > > > > > Gustavo Vieira Goncalves Coelho Rios <gustavo@ifour.com.br> types:
> > > > > > > > I compiled and executed a small program and it's eating about 336
> > > > > > > > of real memory (rss) and 840 of virtual size memory (vsz), may some
> > > > > > > > one explain why a simple program eats about 1 MB of memory?
> > > > > > > You linked it shared, right? That 1MB includes all of every shared
> > > > > > > library it uses, whether it uses those functions or not.
> > > > > > Pardon ! It certainly does not ! That is the point of shared libraries -
> > > > > > the code is *shared* between processes using it. The required code is
> > > > > > then made dynamically available.
> > > > >
> > > > > Shared libraries are mapped into the memory space of the process. As
> > > > > such, they are part of the memory of the process, and should be
> > > > > counted when adding up the memory of the process, so it'll be the rss
> > > > > (if it's resident) and vsz of the process.
> > > > >
> > > > > Whether or not the physical memory is shared is another question, and
> > > > > I'll let you all continue to debate that. I will say that, given the
> > > > > price of disks, if the memory isn't shared, a system with static
> > > > > binaries might be a better choice than one with dynamic binaries.
> > > >
> > > > So what does the word shared in shared memory mean then :)
> > > > Hard to see what the point is if all processes load their own copy
> > > > of shared memory libraries at run time..
> > > > I think you will find that physically speaking there is only one libc...
> > > > in memory under the shared model.
> > >
> > > Since you replied to me, and I didn't have an opinion about shared
> > > libraries being shared on memory or just disk, I'm assuming you're
> > > claiming that my analysis of the way libc is used and the memory
> > > counted.
> > >
> > > Checking usage is easy: just truss a binary that uses shared libc, and
> > > look for it in the output. Here's what I find:
> > >
> > > access("/usr/lib/libc.so.3",0) = 0 (0x0)
> > > open("/usr/lib/libc.so.3",0,027757775424) = 3 (0x3)
> > > fstat(3,0xbfbffae4) = 0 (0x0)
> > > read(0x3,0xbfbfeab4,0x1000) = 4096 (0x1000)
> > > mmap(0x0,643072,0x5,0x2,3,0x0) = 672337920 (0x28131000)
> > > mmap(0x281b5000,20480,0x3,0x12,3,0x83000) = 672878592 (0x281b5000)
> > > mmap(0x281ba000,81920,0x3,0x1012,-1,0x0) = 672899072 (0x281ba000)
> > > close(3) = 0 (0x0)
> > >
> > > I.e. - it gets opened and mmap'ed into memory exactly like I
> > > said. After it's mapped in, a second area is allocated r/w instead of
> > > r/x, and a second r/w area is allocated from swap. They are all part
> > > of the memory used by the process, and show up in the appropriate
> > > sizes.
> > Yes, it is mapped into the processes's address space.
> > It is not copied into it.
>
> Correct. This pretty much settles the question of whether the space is
> shared or not - some of it is, and some of it isn't :-). The first
> segment (628K) is shared and non-writable; the second (20K) is shared
> with copy-on-write, and the third (80K) isn't shared at all. See the
> mmap man page and /usr/include/sys/mman.h for details.
I am familiar with themm:)
> The answer to the original question is still the same, though. The
> reason the virtual set size of the program is so large is that the
> virtual space of the process includes libc.so (by mapping into place),
> which adds nearly 3/4ths of a meg. The resident set size should
> include all pages in that shared hunk of memory that are resident, no
> matter which process using it referenced the page.
>
Ok. But shared libraries have nothing to do with saving disk space..
Cliff
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010122211309.A958>