From owner-freebsd-questions Mon Jan 22 13:38:33 2001 Delivered-To: freebsd-questions@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id F159C37B6A4 for ; Mon, 22 Jan 2001 13:38:13 -0800 (PST) Received: from [212.238.77.116] (helo=gateway.raggedclown.net) by post.mail.nl.demon.net with smtp (Exim 3.14 #4) id 14Kof8-000JSN-00; Mon, 22 Jan 2001 21:38:07 +0000 Received: from buffy.raggedclown.net (btvs.demon.nl [192.168.1.2]) by gateway.raggedclown.net (Postfix) with ESMTP id A8A755DB0; Mon, 22 Jan 2001 22:36:39 +0100 (CET) Received: by buffy.raggedclown.net (Postfix on SuSE Linux 7.0 (i386), from userid 500) id D500712C3D; Mon, 22 Jan 2001 21:13:09 +0100 (CET) Date: Mon, 22 Jan 2001 21:13:09 +0100 From: Cliff Sarginson To: Mike Meyer Cc: Gustavo Vieira Goncalves Coelho Rios , questions@FreeBSD.ORG Subject: Re: small program eats lot of memory Message-ID: <20010122211309.A958@raggedclown.net> References: <14956.14518.590300.22504@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14956.14518.590300.22504@guru.mired.org>; from mwm@mired.org on Mon, Jan 22, 2001 at 07:42:14AM -0600 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 07:42:14AM -0600, Mike Meyer wrote: > 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. 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