Date: Mon, 10 Sep 2007 13:43:05 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 process sizes Message-ID: <20070910104305.GA53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070910101850.GA1146@turion.vk2pj.dyndns.org> References: <20070905095049.GH1167@turion.vk2pj.dyndns.org> <20070905145006.GA50486@team.vega.ru> <46E38930.2050409@wemm.org> <20070910101850.GA1146@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--CtqPPqYpYc7tL2y7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 10, 2007 at 08:18:50PM +1000, Peter Jeremy wrote: > On 2007-Sep-08 22:48:32 -0700, Peter Wemm <peter@wemm.org> wrote: > >1) binutils has the wrong max page size. It is currently set at 1MB rat= her=20 > >than 2MB. I believe this is fixed in binutils sources that we have not= =20 > >imported yet. This is currently harmless, but is less than useful once = we=20 > >have superpages support committed. >=20 > 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). >=20 > I notice that the i386 ld scripts don't bother with superpage alignments. >=20 > >2) There is a bug in sys/kern/imgact_elf.c. It assumes that the PT_LOAD= =20 > >sections are contiguous, which isn't a given. >=20 > 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. >=20 > >process size by eliminating the unnecessary mappings. I'll take a look = and=20 > >see if I can fix it. If somebody else wants to take a shot, be my guest. >=20 > 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. >=20 > 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 memory map. --CtqPPqYpYc7tL2y7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5R+4C3+MBN1Mb4gRAnrWAJ9rbV1o6zHpzUmNdVl7L0NKRTdhMACfSaIB 6Ul5e2BLQkACu4/ryJqRMDY= =PIJa -----END PGP SIGNATURE----- --CtqPPqYpYc7tL2y7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070910104305.GA53667>