Date: Fri, 7 Sep 2007 10:28:08 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes Message-ID: <20070907002808.GA34246@turion.vk2pj.dyndns.org> In-Reply-To: <20070905155354.GG53667@deviant.kiev.zoral.com.ua> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905155354.GG53667@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Sep-05 18:53:54 +0300, Kostik Belousov <kostikbel@gmail.com> wrote: >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(). Looking at map_object(), together with a ktrace of cat(1) make it a lot clearer what it going on. >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. 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). 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 alignme= nt 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. 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 2004= 05:45:40 -0000 1.1.1.6 +++ /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 7 Sep 2007 = 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" [1] being on a vendor branch is not a technical reason --=20 Peter Jeremy --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG4JsY/opHv/APuIcRAquAAKC65PnSGhSt/owUIOZELOH4tdkUDQCfUr30 j1ogMDnH4Ut8YcZA8cS4WUY= =sOc/ -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070907002808.GA34246>