svn commit: r242102 - in head: contrib/bmake usr.bin/bmake

[Peter Jeremy]

[A bit delayed]

On 2012-Nov-15 02:41:22 -0600, "Matthew D. Fuller" <fullermd at over-yonder.net> wrote:
>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.

Not defining MALLOC_PRODUCTION causes quite significant startup
costs for any process that uses malloc() at all.  In this case,
jemalloc verifies that memory obtained from the kernel is zero-filled,
causing (thousands of unnecessary) page faults.  For a short-running
process that doesn't allocate all the space in the jemalloc arenas,
this dominates the runtime - in the case of /bin/echo, I measured
87 page faults with MALLOC_PRODUCTION and 2133 without.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20121201/2c5d9337/attachment.sig>