Date: Tue, 20 Dec 2011 09:27:43 -0800 From: Artem Belevich <art@freebsd.org> To: Ganael LAPLANCHE <ganael.laplanche@martymac.org> Cc: Tijl Coosemans <tijl@coosemans.org>, freebsd-stable@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: Using mmap(2) with a hint address Message-ID: <CAFqOu6h=kuh2HrVo01mS6u8N1R-q3Sjxjj6cbk2jFiXnzSSgKw@mail.gmail.com> In-Reply-To: <4EF0A3A7.80309@FreeBSD.org> References: <20111220080437.M63044@martymac.org> <4EF05F27.8030902@FreeBSD.org> <20111220134716.M62917@martymac.org> <20111220142740.M29405@martymac.org> <4EF0A3A7.80309@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Tue, Dec 20, 2011 at 7:03 AM, Andriy Gapon <avg@freebsd.org> wrote: > on 20/12/2011 16:31 Ganael LAPLANCHE said the following: >> On Tue, 20 Dec 2011 15:02:01 +0100 (CET), Ganael LAPLANCHE wrote >> >>> But there is still something I don't understand : on the Linux >>> machine where I ran my test program, the current RLIMIT_DATA >>> is set to 0xffffffff/0xffffffff and I can manage to mmap at >>> address 0x20000000. If I set the same limit on FreeBSD, I >>> won't get the mapping at 0x20000000. So, there *is* a >>> difference of behaviour between the two systems, but I don't >>> understand why. >> >> Well, in fact, two things remain not very clear for me : >> >> - Why are mmap()s performed *after* data segment ? >> =A0 =3D> It seems they can go within, on GNU/Linux and NetBSD. >> >> - Why do we have such a default value for datasize (8.2, amd64) : >> >> $ limits >> Resource limits (current): >> =A0 cputime =A0 =A0 =A0 =A0 =A0 =A0 =A0infinity secs >> =A0 filesize =A0 =A0 =A0 =A0 =A0 =A0 infinity kB >> =A0 datasize =A0 =A0 =A0 =A0 =A0 =A0 33554432 kB >> >> this is HUGE ! > > Just a guess - this might be some sort of optimization to keep virtual ad= dress > range of dynamic allocations untouched by unrelated mmap calls. =A0Not su= re if > that's so and how useful could that be. Something like that. In the past heap allocator used to get memory from system via sbrk(). It still may do so, if you set MALLOC_OPTIONS=3DD. The problem is that sbrk() can't advance past an area used by something else (i.e. mmaped region) so kernel makes an effort to leave a lot of unused address space which sbrk() may claim later on. These days malloc() by default uses mmap, so if you don't force it to use sbrk() you can probably lower MAXDSIZE and let kernel use most of address space for hinted mmaps. That said, unless you use MAP_FIXED, malloc is not guaranteed to pay attention to hints and the app must be able to deal with that. FreeBSD kernel behavior is just one possible scenario that may affect mmap behavior. Behavior may also change between architectures, or due to preceeding mmaps (think of dynamic linker mapping in shared libraries). If an application relies on hints having effect without MAP_FIXED, it's the app that needs fixing, IMHO. --Artem > svn log / svn annotate of the file may reveal more details. > > -- > Andriy Gapon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFqOu6h=kuh2HrVo01mS6u8N1R-q3Sjxjj6cbk2jFiXnzSSgKw>