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>