Date: Wed, 5 Sep 2007 18:53:54 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes Message-ID: <20070905155354.GG53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070905095049.GH1167@turion.vk2pj.dyndns.org> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--9/eUdp+dLtKXvemk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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:
>=20
> i386 amd64
> 1476 3572 getty
> 6272 29184 xclock
> 4784 28020 xdm
> 6420 30000 xterm
> 3828 9444 sendmail
>=20
> 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:
>=20
> 0x800f60000 0x800fba000 61 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnod=
e /usr/local/lib/libXaw8.so.8
> 0x800fba000 0x800fbb000 1 0 0xffffff002765ed20 r-x 1 0 0x2180 COW NC vnod=
e /usr/local/lib/libXaw8.so.8
> 0x800fbb000 0x8010bb000 18 0 0xffffff0027ac2540 r-x 36 18 0x0 COW NC vnod=
e /usr/local/lib/libXaw8.so.8 [*]
> 0x8010bb000 0x8010cd000 18 0 0xffffff00274d2c40 rw- 1 0 0x2180 COW NC vno=
de /usr/local/lib/libXaw8.so.8
>=20
> 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/loc=
al/lib/libXaw8.so.8
> 0x282d8000 0x282df000 3 0 0xc3aef39c rwx 1 0 0x2180 COW NC vnode /usr/loc=
al/lib/libXaw8.so.8
>=20
> Could someone please explain the purpose of the mapping [*] and what
> system resources they occupy.
On my outdated RELENG_6, relevant part of the
readelf -a /usr/local/lib/libXaw8.so.8
output is
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000005a4ad 0x000000000005a4ad R E 100000
LOAD 0x000000000005b000 0x000000000015b000 0x000000000015b000
0x0000000000011948 0x0000000000011ed0 RW 100000
DYNAMIC 0x000000000006b718 0x000000000016b718 0x000000000016b718
0x00000000000001e0 0x00000000000001e0 RW 8
As you see, virtual address for second loadable section (rw, data+bss) is
0x000000000015b000 (+base). This seems to be due to the alignment that is
0x100000.
The ghost mapping you see is due to the rtld algorithm for mapping the elf
object, that reserves the address space by doing mmap() for full range
where the sections would be located, and then remaps actual segments on the
appropriate offsets. See libexec/rtld-elf/map_object.c::map_object().
The alignment itself seems to come from (or, at least, reflected there)
/usr/libdata/ldscripts/elf_x86_64_fbsd.x* files, see ALIGN calculation
for rw sections.
At the end, the cause seems to be the toolchain configuration, namely, ld.
--9/eUdp+dLtKXvemk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFG3tERC3+MBN1Mb4gRAqEMAKDvyI3t4X30vJdmrUqfxapxKA+SNgCbBgA9
qcQ2OK+HkDpDN6CyuuNokQ0=
=OkZM
-----END PGP SIGNATURE-----
--9/eUdp+dLtKXvemk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070905155354.GG53667>