amd64 process sizes
kostikbel at gmail.com
Mon Sep 10 03:43:16 PDT 2007
On Mon, Sep 10, 2007 at 08:18:50PM +1000, Peter Jeremy wrote:
> On 2007-Sep-08 22:48:32 -0700, Peter Wemm <peter at wemm.org> wrote:
> >1) binutils has the wrong max page size. It is currently set at 1MB rather
> >than 2MB. I believe this is fixed in binutils sources that we have not
> >imported yet. This is currently harmless, but is less than useful once we
> >have superpages support committed.
> I can see the usefulness of superpages for large objects (like the
> kernel and database buffer caches) but do they actually have much
> benefit for normal executables and shared libraries? Looking through
> my set of .so's, I only have 6 that have text segments larger than
> 2MiB (though a 7th is close to 2MiB), the largest (libwx_gtk2) is only
> 5MiB. None of the data or bss segments are larger than 2MiB and (the
> largest is 1.8MiB).
> I notice that the i386 ld scripts don't bother with superpage alignments.
> >2) There is a bug in sys/kern/imgact_elf.c. It assumes that the PT_LOAD
> >sections are contiguous, which isn't a given.
> I've had a quick look through all my process maps and I don't see any
> obvious issues with imgact_elf.c - it looks to be only ld-elf.so.1.
> >process size by eliminating the unnecessary mappings. I'll take a look and
> >see if I can fix it. If somebody else wants to take a shot, be my guest.
> The biggest difficulty I see is that currently ld-elf.so just mmap()s
> the various bits of the requested .so - any alignment is totally up to
> mmap(2). There is no way to request anything other than page alignment.
> I can see potential uses for a "MAP_ALIGN" flag to mmap(2) which would
> treat "addr" as an minimum alignment but no other Unices appear to
> support this. The only other option I can see would be for ld-elf.so
> to second-guess the way mmap(2) works and use a mixture of MAP_FIXED
> and mmap()/munmap() to achieve the required alignment.
Or rtld may map the huge region (twice of alignment) to reserve space that
is guaranteed to contain the address with needed alignment, and then do
use the mixture of MAP_FIXED mmaps and munmap() to stitch the needed
-------------- 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/20070910/d9285d00/attachment.pgp
More information about the freebsd-amd64