Date: Sat, 26 Sep 2009 18:20:40 +0000 (UTC) From: Alan Cox <alc@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/lib/libc/stdlib malloc.3 malloc.c Message-ID: <200909261820.n8QIKwxQ048368@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
alc 2009-09-26 18:20:40 UTC
FreeBSD src repository
Modified files:
lib/libc/stdlib malloc.3 malloc.c
Log:
SVN rev 197524 on 2009-09-26 18:20:40Z by alc
Make malloc(3) superpage aware. Specifically, if getpagesizes(3) returns
a large page size that is greater than malloc(3)'s default chunk size but
less than or equal to 4 MB, then increase the chunk size to match the large
page size.
Most often, using a chunk size that is less than the large page size is not
a problem. However, consider a long-running application that allocates and
frees significant amounts of memory. In particular, it frees enough memory
at times that some of that memory is munmap()ed. Up until the first
munmap(), a 1MB chunk size is just fine; it's not a problem for the virtual
memory system. Two adjacent 1MB chunks that are aligned on a 2MB boundary
will be promoted automatically to a superpage even though they were
allocated at different times. The trouble begins with the munmap(),
releasing a 1MB chunk will trigger the demotion of the containing superpage,
leaving behind a half-used 2MB reservation. Now comes the real problem.
Unfortunately, when the application needs to allocate more memory, and it
recycles the previously munmap()ed address range, the implementation of
mmap() won't be able to reuse the reservation. Basically, the coalescing
rules in the virtual memory system don't allow this new range to combine
with its neighbor. The effect being that superpage promotion will not
reoccur for this range of addresses until both 1MB chunks are freed at some
point in the future.
Reviewed by: jasone
MFC after: 3 weeks
Revision Changes Path
1.81 +4 -2 src/lib/libc/stdlib/malloc.3
1.185 +15 -0 src/lib/libc/stdlib/malloc.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909261820.n8QIKwxQ048368>