7.0 CPU and Memory Performance
Jason Evans
jasone at FreeBSD.org
Wed Aug 13 22:35:02 UTC 2008
Kris Kennaway wrote:
> Tim Traver wrote:
>> And here is the run of the ubench.5.4 binary:
>> FreeBSD 7.0 - CPU 139,623 - MEM - 207,180
>>
>> And a rerun of the FreeBSD 7.0 ubench making sure there is absolutely
>> no activity on the box
>> FreeBSD 7.0 - CPU 200,562 - MEM - 107,695
>>
>> That run is a little better than the previous one, but there seems to
>> still be quite a difference in the memory tests...
>>
>> Does that show anything ????
>
> It shows that if there is a difference it is probably in userland, not
> the kernel. The obvious guess is the new malloc in 7.0. As for whether
> it indicates a bug, someone would have to look more closely at what
> ubench does. The author's description of his benchmark doesn't inspire
> confidence: it does "rather senseless memory allocation and memory to
> memory copying operations for another 3 mins concurrently using several
> processes".
The ubench memory benchmark operates almost entirely on 1024B buffers,
which is nearly worst case for jemalloc. Also, its memory use
fluctuates wildly, in a pattern that causes a lot of dirty page flushing
and chunk map/unmap activity. That is where most of the difference is;
jemalloc is more aggressive/effective in returning pages to the VM than
is phkmalloc. In order to verify the cause of the performance
difference, I ran ubench (on an 8-current system) with
MALLOC_OPTIONS=7F6K (avoid flushing dirty pages, and use 64-MiB chunks
in order to avoid repeatedly mapping/unmapping chunks), and the ubench
memory benchmark sped up by ~51%. With the default configuration,
jemalloc was ~13% slower than phkmalloc, but with 7F6K it was ~31%
faster than phkmalloc.
On possible factor for stock FreeBSD 7.0 is a scalability issue that I
MFC'ed a fix for in r176922 on 7 March (shortly after the 7.0 release).
And, there's a non-trivial overall performance improvement that I'm
planning to MFC this week.
I encourage you to find some better way of testing memory performance
than ubench. Generic malloc benchmarking is *hard*. The most effective
approach for someone not specifically interested in allocators is to
benchmark the actual applications that will be run in production. If
you find that jemalloc performs poorly in such circumstances, please let
me know the details so that I can look into possible improvements.
Thanks,
Jason
More information about the freebsd-performance
mailing list