From owner-freebsd-amd64@FreeBSD.ORG Wed Sep 5 15:29:52 2007 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0C5516A419 for ; Wed, 5 Sep 2007 15:29:52 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (mx1.vega.ru [87.242.77.163]) by mx1.freebsd.org (Postfix) with ESMTP id 85B0113C48A for ; Wed, 5 Sep 2007 15:29:52 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=61407 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1ISwDF-0009O0-As; Wed, 05 Sep 2007 14:50:37 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.1/8.14.1) with ESMTP id l85Eo7n3050664; Wed, 5 Sep 2007 18:50:07 +0400 (MSD) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.1/8.14.1/Submit) id l85Eo6dR050659; Wed, 5 Sep 2007 18:50:06 +0400 (MSD) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Wed, 5 Sep 2007 18:50:06 +0400 From: Ruslan Ermilov To: Peter Jeremy Message-ID: <20070905145006.GA50486@team.vega.ru> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070905095049.GH1167@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 15:29:52 -0000 On Wed, Sep 05, 2007 at 07:50:49PM +1000, Peter Jeremy wrote: > I've been comparing VSZ reported for similar processes on amd64 and > i386 and found that amd64 processes report as vastly larger than I > expected: > > i386 amd64 > 1476 3572 getty > 6272 29184 xclock > 4784 28020 xdm > 6420 30000 xterm > 3828 9444 sendmail > > I did some further digging into the procfs map for xterm and found > that each of the amd64 shared objects has an additional mapping that > is 255 or 256 pages. Once you remove those mappings, the sizes are > reasonably similar. A typical set of mappings is: > > 0x800f60000 0x800fba000 61 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnode /usr/local/lib/libXaw8.so.8 > 0x800fba000 0x800fbb000 1 0 0xffffff002765ed20 r-x 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 > 0x800fbb000 0x8010bb000 18 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnode /usr/local/lib/libXaw8.so.8 [*] > 0x8010bb000 0x8010cd000 18 0 0xffffff00274d2c40 rw- 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 > > 0x28284000 0x282d7000 15 0 0xc360ad68 r-x 9 6 0x0 COW NC vnode /usr/local/lib/libXaw8.so.8 > 0x282d7000 0x282d8000 0 0 0xc3a4b210 r-x 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 > 0x282d8000 0x282df000 3 0 0xc3aef39c rwx 1 0 0x2180 COW NC vnode /usr/local/lib/libXaw8.so.8 > > Could someone please explain the purpose of the mapping [*] and what > system resources they occupy. > These mappings are produced by rtld(1) when it maps shared objects. I took cat(1) here, and examined its libc.so's mappings on i386 and amd64. What rtld(1) basically does is mmap's the PT_LOAD segments (see the Program Header in the "objdump -x /lib/libc.so.*" output). Since the size of the loadable segment is not necessaily a multiple of the page size, it zeroes out the rest of the last page of each loadable segment. If the segment is read-only (like is the case for the "text" segment), it temporarily write-unprotects the last page, then zeroes its tail, then makes it read-only again. The first mapping you see is created by mapping a "text" segment of the library. The last mapping is for the "data" segment. The second mapping is created by toggling the write protection of the page, and this mapping is 4096 bytes in size. The mysterious third mapping on amd64 is due to a gap between the virtual addresses of the two loadable segments (text and data) on amd64: Program Header: LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**20 filesz 0x00000000000d7051 memsz 0x00000000000d7051 flags r-x LOAD off 0x00000000000d7060 vaddr 0x00000000001d7060 paddr 0x00000000001d7060 align 2**20 filesz 0x000000000001a010 memsz 0x0000000000032df8 flags rw- vend0 = rounddown(vaddr0, pagesize) + roundup(memsz0, pagesize) = 0x0 + 0xd8000 = 0xd8000 gap = rounddown(vaddr1, pagesize) - vend0 = 0x1d7000 - 0xd8000 = 255 pages On i386 there's no gap: Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x000ca5d2 memsz 0x000ca5d2 flags r-x LOAD off 0x000ca5e0 vaddr 0x000cb5e0 paddr 0x000cb5e0 align 2**12 filesz 0x000053f0 memsz 0x0001b404 flags rw- vend0 = rounddown(vaddr0, pagesize) + roundup(memsz0, pagesize) = 0x0 + 0xcb000 = 0xcb000 gap = rounddown(vaddr1, pagesize) - vend0 = 0xcb000 - 0xcb000 = 0 pages Why amd64 linker does so, I don't know. :-) Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer