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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
