Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Nov 2012 02:41:22 -0600
From:      "Matthew D. Fuller" <fullermd@over-yonder.net>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, "David E. O'Brien" <obrien@FreeBSD.org>, svn-src-head@FreeBSD.org, "Simon J. Gerraty" <sjg@FreeBSD.org>, Chris Rees <utisoft@gmail.com>
Subject:   Re: svn commit: r242102 - in head: contrib/bmake usr.bin/bmake
Message-ID:  <20121115084121.GI66994@over-yonder.net>
In-Reply-To: <20121115151622.J1179@besplex.bde.org>
References:  <201210252318.q9PNI6IQ069461@svn.freebsd.org> <20121114172823.GA20127@dragon.NUXI.org> <20121114184837.GA73505@kib.kiev.ua> <CADLo83_TQ0213jeo16J5X=vdKVbbYPq=WN2HZJCLkKMCP=RkFA@mail.gmail.com> <20121115151622.J1179@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121115084121.GI66994>