From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 21 12:08:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F141106564A for ; Fri, 21 Oct 2011 12:08:53 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id DCADB8FC0C for ; Fri, 21 Oct 2011 12:08:52 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RHDu1-0001iR-JT for freebsd-hackers@freebsd.org; Fri, 21 Oct 2011 14:08:45 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Oct 2011 14:08:45 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Oct 2011 14:08:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 21 Oct 2011 14:08:29 +0200 Lines: 61 Message-ID: References: <4EA0610B.90206@gmail.com> <20111021084413.GA46039@server.vk2pj.dyndns.org> <4EA1471E.9050501@gmail.com> <4EA15004.50308@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig75685E8576A963ABF750171C" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 In-Reply-To: <4EA15004.50308@gmail.com> X-Enigmail-Version: 1.1.2 Subject: Re: Measuring memory footprint in C/C++ code on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 12:08:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75685E8576A963ABF750171C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21/10/2011 12:57, Razmig K wrote: > Le 21.10.2011 12:26, Ivan Voras a =C3=A9crit : >> Well, do you know that SIZE in top is virtual memory size, not residen= t >> size (which is the "RES" column)? You can allocate whatever you want >> from virtual memory, it is not "used" until it's touched. >=20 > Yes, I do. So do you suggest using RES as a better indicator of memory > footprint? Almost certainly yes. Measuring virtual memory is significantly less important for real-world loads. Some of this is very nicely described here: https://www.varnish-cache.org/trac/wiki/ArchitectNotes . > The program in question processes large 3D images via vtk, and I'd like= > to measure its memory usgae with different parameter configurations as > the maximum amount of memory acquired during execution. Since SIZE ofte= n > happens to be larger than RES, and increase more during execution, I > thought of using it as an indicator of memory footprint. No; the difference between SIZE and RES is "slack space" - allocated but untouched virtual memory, which is *NOT PRESENT IN RAM*. You can verify this yourself: make a small C program and allocate twice the physical memory (+swap) you have on the machine (try terabytes on a 64-bit machine), and it will succeed. If you look at this program in top, it should (barring some optimizations) show you that SIZE is huge, but RES is a couple of MB, basically like you didn't allocate anything at all. Now, it is a whole other thing if you try to actually *use* this memory you've allocated. Here's a random link on the topic from Google: http://opsmonkey.blogspot.com/2007/01/linux-memory-overcommit.html . Unfortunately, the phrase "memory overcommit" has been hijacked by the virtualization environment to mean the same thing but relating to the memory in virtual machines. --------------enig75685E8576A963ABF750171C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6hYL0ACgkQldnAQVacBch22QCg38zjUUahKydX8V5IFbeFXcDB leMAniWcI5UM+w1YoZFlpqu8fstCp93v =SRBe -----END PGP SIGNATURE----- --------------enig75685E8576A963ABF750171C--