performance regression after 3.1

[Jason Evans]

On Jun 1, 2013, at 1:53 PM, Xose Vazquez Perez <xose.vazquez at gmail.com> wrote:
> 3.1 : is fine
> 3.2 : bad performance <---- bug since 3.2
> 3.3.x : bad performance
> git-tree : bad performance
> 
> OS: Fedora 17
> kernel: 3.9.4-100
> x86_64 machine
> 
> test done with ebizzy-0.3 <http://ebizzy.sf.net>
> code: http://sf.net/projects/ebizzy/files/latest/download?source=files
> 
> jemalloc-3.3.1:
> 
> $ LD_PRELOAD=/usr/lib64/libjemalloc.so.1 ./ebizzy -s 131072
> 47525 records/s
> 
> […]
> 
> Same test done with jemalloc-3.1.0 (glibc-2.15 and tcmalloc-2.0 get similar results):
> 
> $ LD_PRELOAD=/home/xose/bajar/j/3.1/lib64/libjemalloc.so.1 ./ebizzy -s 131072
> 335568 records/s
> 
> […]

This is due to the following change:

	http://www.canonware.com/cgi-bin/gitweb.cgi?p=jemalloc.git;a=commitdiff;h=e3d13060c8a04f08764b16b003169eb205fa09eb

Specifically, this part of the change:

Remove the limitation that prevented purging unless at least one chunk
worth of dirty pages had accumulated in an arena.  This limitation was
intended to avoid excessive purging for small applications, but the
threshold was arbitrary, and the effect of questionable utility.

In essence, the effect you're seeing is due to the microbenchmark nature of ebizzy.  The allocator threads in ebizzy each have a working set that oscillates between 0 and 131071 bytes; every free() call causes an madvise() call.  Set MALLOC_CONF=lg_dirty_mult:-1 to measure performance with unused dirty page purging disabled.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20130602/17b1bcb2/attachment.html>