From owner-svn-src-all@FreeBSD.ORG Thu Nov 15 08:48:20 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0F34DFC; Thu, 15 Nov 2012 08:48:19 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id A83488FC15; Thu, 15 Nov 2012 08:48:19 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id A9E6537B70D; Thu, 15 Nov 2012 02:41:22 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3Y2GJL0TlWzXlF; Thu, 15 Nov 2012 02:41:22 -0600 (CST) Date: Thu, 15 Nov 2012 02:41:22 -0600 From: "Matthew D. Fuller" To: Bruce Evans Subject: Re: svn commit: r242102 - in head: contrib/bmake usr.bin/bmake Message-ID: <20121115084121.GI66994@over-yonder.net> References: <201210252318.q9PNI6IQ069461@svn.freebsd.org> <20121114172823.GA20127@dragon.NUXI.org> <20121114184837.GA73505@kib.kiev.ua> <20121115151622.J1179@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20121115151622.J1179@besplex.bde.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, "David E. O'Brien" , svn-src-head@FreeBSD.org, "Simon J. Gerraty" , Chris Rees X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:48:20 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 15, 2012 at 06:07:27PM +1100 I heard the voice of Bruce Evans, and lo! it spake thus: > > Maybe malloc() would be faster with MALLOC_PRODUCTION. I use > /etc/malloc.conf -> aj locally. freefall doesn't have > /etc/malloc.conf. MALLOC_OPTIONS no longer works, and MALLOC_CONF > is too large for me to understand, so I don't know how to turn off > non-production features dynamically. FWIW, I suspected MALLOC_PRODUCTION in some massive slowdowns I see from time to time on my -CURRENT box. Most vividly around running portupgrade-related bits (portupgrade, pkgdb, etc). I got annoyed by it enough a few weeks ago to write up a quickie to bang malloc() around and see what happened. Attached, just for grins. It allocates a big array, frees every other element, allocates another, frees every other, hops back and forth filling in the holes, then hopes around free'ing everything. Doesn't put anything in the pages, just allocates, so it doesn't call on the VM subsystem for much. i.e., "just beat the snot out of malloc" ;) Here are some quick comparative runs on two systems I have here locally, one running stable/9 (late Jun), the other head (mid Oct). Same binary on both, so it's not a compiler difference either. stable/9: 1.594u 0.142s 0:01.73 100.0% 5+2767k 0+0io 0pf+0w 1.586u 0.157s 0:01.74 99.4% 5+2792k 0+0io 0pf+0w 1.567u 0.156s 0:01.72 99.4% 5+2786k 0+0io 0pf+0w 1.583u 0.211s 0:01.79 100.0% 5+2783k 0+0io 0pf+0w 1.599u 0.126s 0:01.72 99.4% 5+2786k 0+0io 0pf+0w head: 12.748u 0.165s 0:12.91 99.9% 5+167k 0+0io 0pf+0w 12.755u 0.157s 0:12.91 99.9% 5+167k 0+0io 0pf+0w 12.778u 0.157s 0:12.94 99.8% 5+167k 0+0io 0pf+0w 12.657u 0.204s 0:12.86 99.9% 5+167k 0+0io 0pf+0w 12.733u 0.173s 0:12.98 99.3% 5+167k 0+0io 0pf+0w Neither system is entirely quiescent, but they're both largely idle. The CPU's are from the same model series, though the -CURRENT box is 500MHz faster, and has faster memory. So, yeah, it's a safe bet that non-_PRODUCTION malloc() can hurt you quite a lot when you're malloc()-heavy. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. --M9NhX3UHpAaciwkO--