Date: Wed, 13 Aug 2008 23:10:03 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Tim Traver <tt-list@simplenet.com> Cc: freebsd-performance@freebsd.org, Robert Watson <rwatson@FreeBSD.org>, Jason Evans <jasone@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org> Subject: Re: 7.0 CPU and Memory Performance Message-ID: <48A34DAB.6090204@FreeBSD.org> In-Reply-To: <48A34B84.4090100@simplenet.com> References: <48A1F379.2040805@simplenet.com> <alpine.BSF.1.10.0808130939100.70092@fledge.watson.org> <48A33015.2080900@simplenet.com> <48A332FC.20600@FreeBSD.org> <48A34B84.4090100@simplenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Traver wrote: > Kris Kennaway wrote: >>> Robert, >>> >>> ok, I looked and it looks like the port compiles statically, and I was >>> able to grab the binary from the old disk and move it over to the new >>> one... >>> >>> here is info now on how it is linked : >>> >>> [root ~]# ldd ubench.5.4 >>> ubench.5.4: >>> libm.so.3 => /usr/local/lib/compat/libm.so.3 (0x2807e000) >>> libc.so.5 => /usr/local/lib/compat/libc.so.5 (0x28099000) >>> [root ~]# ldd /usr/local/bin/ubench >>> /usr/local/bin/ubench: >>> libm.so.5 => /lib/libm.so.5 (0x2807f000) >>> libc.so.7 => /lib/libc.so.7 (0x28094000) >>> >>> where ubench is the locally compiled one... >>> >>> For reference, here are the old stats >>> FreeBSD 5.4 - CPU 112,721 - MEM - 146,483 >>> FreeBSD 7.0 - CPU 177,339 - MEM - 95,920 >>> >>> 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". >> >> Kris > Kris, > > ok, so is there anything I can do to help????? or, I noticed you cc'ed > some of the other performance guys...they going to check it out? jasone is the je in jemalloc, so maybe he will be able to comment on whether whatever the heck ubench does is an abnormally pessimal case for it, or something. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48A34DAB.6090204>