From owner-cvs-src-old@FreeBSD.ORG Sat Sep 26 18:20:58 2009 Return-Path: Delivered-To: cvs-src-old@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B842106568F for ; Sat, 26 Sep 2009 18:20:58 +0000 (UTC) (envelope-from alc@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 89ABE8FC1D for ; Sat, 26 Sep 2009 18:20:58 +0000 (UTC) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n8QIKw6m048369 for ; Sat, 26 Sep 2009 18:20:58 GMT (envelope-from alc@repoman.freebsd.org) Received: (from svn2cvs@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n8QIKwxQ048368 for cvs-src-old@freebsd.org; Sat, 26 Sep 2009 18:20:58 GMT (envelope-from alc@repoman.freebsd.org) Message-Id: <200909261820.n8QIKwxQ048368@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: svn2cvs set sender to alc@repoman.freebsd.org using -f From: Alan Cox Date: Sat, 26 Sep 2009 18:20:40 +0000 (UTC) To: cvs-src-old@freebsd.org X-FreeBSD-CVS-Branch: HEAD Subject: cvs commit: src/lib/libc/stdlib malloc.3 malloc.c X-BeenThere: cvs-src-old@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2009 18:20:58 -0000 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