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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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> 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 alignment > > 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. > > 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 > =================================================================== > 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=64 > OUTPUT_FORMAT="elf64-x86-64" > TEXT_START_ADDR=0x400000 > -MAXPAGESIZE=0x100000 > +MAXPAGESIZE=0x1000 > COMMONPAGESIZE=0x1000 > NONPAGED_TEXT_START_ADDR=0x400000 > ARCH="i386:x86-64" > > [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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4UStC3+MBN1Mb4gRAgNQAJ9TY1XBzPcbu5qNkTqsNcloDTxGZQCgx8xg SgsFnUp6e/JM7TLsNcKxsx8= =1Rxx -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070907123142.GK53667>