amd64 process sizes

[Kostik Belousov]

On Fri, Sep 07, 2007 at 10:28:08AM +1000, Peter Jeremy wrote:
> On 2007-Sep-05 18:53:54 +0300, Kostik Belousov <kostikbel at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20070907/bd7dc5e8/attachment.pgp