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>