[A bit delayed] On 2012-Nov-15 02:41:22 -0600, "Matthew D. Fuller" <fulle...@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
pgpCEY8jxCTmb.pgp
Description: PGP signature