Date: Fri, 7 Sep 2007 15:31:42 +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: <20070907123142.GK53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070907002808.GA34246@turion.vk2pj.dyndns.org> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905155354.GG53667@deviant.kiev.zoral.com.ua> <20070907002808.GA34246@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0FM4RQAc0jwHekq5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2007 at 10:28:08AM +1000, Peter Jeremy wrote: > On 2007-Sep-05 18:53:54 +0300, Kostik Belousov <kostikbel@gmail.com> wrot= e: > >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 e= lf > >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(). >=20 > Looking at map_object(), together with a ktrace of cat(1) make it a > lot clearer what it going on. >=20 > >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. >=20 > These ldscript files are themselves generated based on constants in > /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh - which > incorrectly states that the amd64 max page size is 1MB (this is > corrected in the FSF CVS repo between binutils 2.17 and 2.18). >=20 > The intent appears to be to align sections on PDE boundaries. I'm > not sure what purpose this might serve but it definitely doesn't > work because: > 1) The PDE boundary is 2MB, not 1MB as currently configured > 2) ld-elf.so.1 makes no attempt to support anything other than page align= ment >=20 > As a result, the only effect of this configuration is to vastly bloat > the VSZ of processes - whilst these pages will never be accessed, > there will still be some associated KVM bloat to support the increased > VSZ and number of vm_map_entry's associated with processes. I don't > know enough about the VM system to quantify this. It seems to be negligible. >=20 > Can anyone suggest a technical reason[1] for not applying the following > patch to remove the 1MB "max page size": > Index: /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/ncvs/src/contrib/binutils/ld/emulparams/elf_x86_64.sh,v > retrieving revision 1.1.1.6 > diff -u -r1.1.1.6 elf_x86_64.sh > --- /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 16 Jun 20= 04 05:45:40 -0000 1.1.1.6 > +++ /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 7 Sep 200= 7 00:20:31 -0000 > @@ -2,7 +2,7 @@ > ELFSIZE=3D64 > OUTPUT_FORMAT=3D"elf64-x86-64" > TEXT_START_ADDR=3D0x400000 > -MAXPAGESIZE=3D0x100000 > +MAXPAGESIZE=3D0x1000 > COMMONPAGESIZE=3D0x1000 > NONPAGED_TEXT_START_ADDR=3D0x400000 > ARCH=3D"i386:x86-64" >=20 > [1] being on a vendor branch is not a technical reason If working, patch seems to be good. Maybe, we shall look whether the linux distribution did something with this. And, I think that the question shall be actually asking to binutils developers. --0FM4RQAc0jwHekq5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4UStC3+MBN1Mb4gRAgNQAJ9TY1XBzPcbu5qNkTqsNcloDTxGZQCgx8xg SgsFnUp6e/JM7TLsNcKxsx8= =1Rxx -----END PGP SIGNATURE----- --0FM4RQAc0jwHekq5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070907123142.GK53667>