amd64 process sizes

[Peter Wemm]

Kostik Belousov wrote:
> 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.
>   
No.  It's our bug.  This layout is by design, in order to make best use 
of large pages.  The correct change here is to change from 0x100000 to 
0x200000 like binutils itself has done.

Then we can fix the rtld or imgact_elf bugs that bogusly map this extra 
space.

-Peter