amd64 process sizes

Peter Jeremy peterjeremy at
Thu Sep 6 17:28:11 PDT 2007

On 2007-Sep-05 18:53:54 +0300, Kostik Belousov <kostikbel at> 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/ - 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) 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.

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/
RCS file: /usr/ncvs/src/contrib/binutils/ld/emulparams/,v
retrieving revision
diff -u -r1.1.1.6
--- /usr/src/contrib/binutils/ld/emulparams/       16 Jun 2004 05:45:40 -0000
+++ /usr/src/contrib/binutils/ld/emulparams/       7 Sep 2007 00:20:31 -0000
@@ -2,7 +2,7 @@

[1] being on a vendor branch is not a technical reason

Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-amd64 mailing list