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