From owner-freebsd-questions Mon Jan 22 5:42:43 2001 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id C782A37B69D for ; Mon, 22 Jan 2001 05:42:20 -0800 (PST) Received: (qmail 10202 invoked by uid 100); 22 Jan 2001 13:42:14 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14956.14518.590300.22504@guru.mired.org> Date: Mon, 22 Jan 2001 07:42:14 -0600 (CST) To: Cliff Sarginson Cc: Mike Meyer , Gustavo Vieira Goncalves Coelho Rios , questions@FreeBSD.ORG Subject: Re: small program eats lot of memory In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cliff Sarginson types: > > Cliff Sarginson types: > > > > Cliff Sarginson types: > > > > > On Sunday 21 January 2001 16:48, Mike Meyer wrote: > > > > > > Gustavo Vieira Goncalves Coelho Rios 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. 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. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message