amd64 process sizes
kostikbel at gmail.com
Fri Sep 7 05:31:54 PDT 2007
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
> >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 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 184.108.40.206
> diff -u -r220.127.116.11 elf_x86_64.sh
> --- /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 16 Jun 2004 05:45:40 -0000 18.104.22.168
> +++ /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 7 Sep 2007 00:20:31 -0000
> @@ -2,7 +2,7 @@
>  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
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20070907/bd7dc5e8/attachment.pgp
More information about the freebsd-amd64