7.0 CPU and Memory Performance

Tim Traver tt-list at simplenet.com
Wed Aug 13 21:00:54 UTC 2008


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?

Tim.




More information about the freebsd-performance mailing list