Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Dec 2005 18:05:03 +0800
From:      David Xu <davidxu@freebsd.org>
To:        Jason Evans <jasone@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: New malloc ready, take 42
Message-ID:  <43ABCBCF.8060500@freebsd.org>
In-Reply-To: <E1E22E2D-A6D5-49CC-9649-C37C50F0443B@freebsd.org>
References:  <E1E22E2D-A6D5-49CC-9649-C37C50F0443B@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote:
> On 28 November, I announced a new malloc implementation that I've  been 
> working on as a replacement for the current libc malloc.  The  main goal 
> for this rewrite of malloc is to provide better scalability  for 
> multi-threaded programs on SMP systems, without degrading  performance 
> in general.  The benchmarks I've run indicate that the  code now meets 
> this goal.
>  ...

Great!

> ===
> === Benchmarking ad nauseam ===
> ===
  > ==> sh6bench (single-threaded)
>...
> phkmalloc doesn't fare very well with its default settings since the  
> benchmark's memory usage fluctuates enough to cause phkmalloc to  
> repeatedly allocate and free pages.  Therefore I report numbers for  
> multiple MALLOC_OPTIONS settings.  Since the program prompts for  
> interactive input, I report the sum of user and sys time, rather than  
> wall time.  (Same VMware setup as for super-smack benchmarks.)
> 
>                     user+sys time (seconds)
> phkmalloc 'aj':     25.66, 25.78, 22.50
> phkmalloc 'aj>>>>': 13.72, 13.77, 13.69
> jemalloc 'aj':      17.88, 17.05, 17.10
> 
> If phkmalloc's cache size is increased adequately, it beats  jemalloc.  
> jemalloc simply has to do more work when splitting and  coalescing 
> regions than phkmalloc does, and this benchmark severely  stresses that 
> aspect of jemalloc.  It's perhaps worth noting that  jemalloc's peak 
> memory usage is ~22% lower than phkmalloc's, which  means that it's 
> doing a better job of avoiding fragmentation.  At  least the extra 
> algorithmic overhead gains us something.
> 
If I have linked " aj>>>>>>>" to /etc/malloc.conf for phkmalloc, the
super-smack get better result, on my Pentium-D 2.8Ghz machine,
before this set,  the select-key.smack can only reach 19500 q_per_s,
after the set, it can reach 20791.33 q_per_s !
The '>' option should be supported in jemalloc because mysql relies
on it.

> So, how about it?  Is jemalloc ready to go in now?
> 
> Thanks,
> Jason

In general, it is fine to me, I don't have other use-cases to test,
others may try apache web benchmark etcs?

David Xu



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