Date: Wed, 13 Aug 2008 21:16:12 +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: <48A332FC.20600@FreeBSD.org> In-Reply-To: <48A33015.2080900@simplenet.com> References: <48A1F379.2040805@simplenet.com> <alpine.BSF.1.10.0808130939100.70092@fledge.watson.org> <48A33015.2080900@simplenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tim Traver wrote: > > Robert Watson wrote: >> On Tue, 12 Aug 2008, Tim Traver wrote: >> >>> I have recently had the opportunity to upgrade a few servers from old >>> versions of 5.4 to 7.0, and have seen some interesting data. Before >>> doing this, I wanted to take some benchmarks to see how the scripts >>> that I would run would fare between the two versions, and the results >>> are somewhat confusing... >> There are potentially a lot of variables here, you migh want to try >> fiddling with the following and see what difference it makes: >> >> (1) Try both 4BSD and ULE in 7.0 -- they have different properties, >> and at the >> very least it would be nice to see what impact it has. >> >> (2) Statically compile the 5.4 binary, and run the same binary on both >> 5.4 and >> 7.0 -- there have been lots of compiler changes, which might be >> relevant. >> >> Also, can you confirm that you're running either 32-bit or 64-bit >> kernels consistently on both versions of FreeBSD? >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> >> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48A332FC.20600>