From owner-cvs-all@FreeBSD.ORG Mon Jul 19 07:00:39 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 344E616A5B9; Mon, 19 Jul 2004 07:00:39 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D2043D46; Mon, 19 Jul 2004 07:00:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.200] ([192.168.0.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6J76ZbW052088; Mon, 19 Jul 2004 01:06:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40FB718B.7080206@samsco.org> Date: Mon, 19 Jul 2004 01:00:27 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040702 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Feldman References: <200407190621.i6J6LRWJ019976@repoman.freebsd.org> In-Reply-To: <200407190621.i6J6LRWJ019976@repoman.freebsd.org> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys malloc.h src/sys/kern kern_malloc.c src/sys/vm vm_contig.c vm_page.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2004 07:00:39 -0000 This is a pretty darn big change to something that is so vital to so many drivers (not including busdma, which means that this touches nearly every driver). Who reviewed this? Was it discussed on a public mailing list? What kind of testing was done for it? If you can't answer these questions then I'm not terribly thrilled. Scott Brian Feldman wrote: > green 2004-07-19 06:21:27 UTC > > FreeBSD src repository > > Modified files: > sys/sys malloc.h > sys/kern kern_malloc.c > sys/vm vm_contig.c vm_page.h > Log: > Reimplement contigmalloc(9) with an algorithm which stands a greatly- > improved chance of working despite pressure from running programs. > Instead of trying to throw a bunch of pages out to swap and hope for > the best, only a range that can potentially fulfill contigmalloc(9)'s > request will have its contents paged out (potentially, not forcibly) > at a time. > > The new contigmalloc operation still operates in three passes, but it > could potentially be tuned to more or less. The first pass only looks > at pages in the cache and free pages, so they would be thrown out > without having to block. If this is not enough, the subsequent passes > page out any unwired memory. To combat memory pressure refragmenting > the section of memory being laundered, each page is removed from the > systems' free memory queue once it has been freed so that blocking > later doesn't cause the memory laundered so far to get reallocated. > > The page-out operations are now blocking, as it would make little sense > to try to push out a page, then get its status immediately afterward > to remove it from the available free pages queue, if it's unlikely to > have been freed. Another change is that if KVA allocation fails, the > allocated memory segment will be freed and not leaked. > > There is a sysctl/tunable, defaulting to on, which causes the old > contigmalloc() algorithm to be used. Nonetheless, I have been using > vm.old_contigmalloc=0 for over a month. It is safe to switch at > run-time to see the difference it makes. > > A new interface has been used which does not require mapping the > allocated pages into KVA: vm_page.h functions vm_page_alloc_contig() > and vm_page_release_contig(). These are what vm.old_contigmalloc=0 > uses internally, so the sysctl/tunable does not affect their operation. > > When using the contigmalloc(9) and contigfree(9) interfaces, memory > is now tracked with malloc(9) stats. Several functions have been > exported from kern_malloc.c to allow other subsystems to use these > statistics, as well. This invalidates the BUGS section of the > contigmalloc(9) manpage. > > Revision Changes Path > 1.135 +48 -28 src/sys/kern/kern_malloc.c > 1.77 +2 -0 src/sys/sys/malloc.h > 1.36 +270 -36 src/sys/vm/vm_contig.c > 1.132 +3 -0 src/sys/vm/vm_page.h