7.0 CPU and Memory Performance

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

7.0 CPU and Memory Performance

Tim Traver
Hi All,

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...

I tried to get as many ducks in a row before posting this, cause i don't
want to waste any of the developers precious time, but I can't guarantee
that my methods were not flawed.

For simplicity, I used a port called ubench (the latest version 0.3,
which I know is quite old) to get the following numbers :

Since I was doing this on the same machine, with completely different
builds (not simply a compile upgrade, but a full install), I figure it
doesn't really matter what kind of machine it is, but just for grins, it
is a Dual Opteron with 2GB of memory in it, compiled with the i386 confs.

The 7.0 is compiled with the ULE scheduler...

The following are averages of at least 5 runs :

FreeBSD 5.4 - CPU 112,721 - MEM - 146,483
FreeBSD 7.0 - CPU 177,339 - MEM - 95,920

Now, I really don't know exactly what the ubench program is doing, but I
think the description says that it is doing random integer and floating
point operations for the CPU tests, and random memory allocation and
copying for the memory test.

So, can we explain the difference???? It looks like the latest SMP code
allows it to process more operations, but what happened to the memory
operations????

Just to get an idea of what this was going to do to my scripts, I tried
some benchmarks for those as well.

I tried to run a PHP script using php 4.4.7 and got the following results :

Using "time php index.php" to get the real time :

FreeBSD 5.4 - 0.290 seconds
FreeBSD 7.0 - 0.335 seconds

So, do the slower memory operations cause that difference in the real
time it takes to run that script???

Thanks,

Tim.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Alfred Perlstein-2
Hey Tim, please try a later version of FreeBSD 7, there's been
many improvements in the malloc(3) code since 7.0 so these
results aren't very meaningful.

Can you let us know what you see with 7-stable?

thanks,
-Alfred


* Tim Traver <[hidden email]> [080812 14:39] wrote:

> Hi All,
>
> 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...
>
> I tried to get as many ducks in a row before posting this, cause i don't
> want to waste any of the developers precious time, but I can't guarantee
> that my methods were not flawed.
>
> For simplicity, I used a port called ubench (the latest version 0.3,
> which I know is quite old) to get the following numbers :
>
> Since I was doing this on the same machine, with completely different
> builds (not simply a compile upgrade, but a full install), I figure it
> doesn't really matter what kind of machine it is, but just for grins, it
> is a Dual Opteron with 2GB of memory in it, compiled with the i386 confs.
>
> The 7.0 is compiled with the ULE scheduler...
>
> The following are averages of at least 5 runs :
>
> FreeBSD 5.4 - CPU 112,721 - MEM - 146,483
> FreeBSD 7.0 - CPU 177,339 - MEM - 95,920
>
> Now, I really don't know exactly what the ubench program is doing, but I
> think the description says that it is doing random integer and floating
> point operations for the CPU tests, and random memory allocation and
> copying for the memory test.
>
> So, can we explain the difference???? It looks like the latest SMP code
> allows it to process more operations, but what happened to the memory
> operations????
>
> Just to get an idea of what this was going to do to my scripts, I tried
> some benchmarks for those as well.
>
> I tried to run a PHP script using php 4.4.7 and got the following results :
>
> Using "time php index.php" to get the real time :
>
> FreeBSD 5.4 - 0.290 seconds
> FreeBSD 7.0 - 0.335 seconds
>
> So, do the slower memory operations cause that difference in the real
> time it takes to run that script???
>
> Thanks,
>
> Tim.
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to
> "[hidden email]"

--
- Alfred Perlstein
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Robert N. M. Watson-2
In reply to this post by Tim Traver

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

>
> I tried to get as many ducks in a row before posting this, cause i don't want
> to waste any of the developers precious time, but I can't guarantee that my
> methods were not flawed.
>
> For simplicity, I used a port called ubench (the latest version 0.3, which I
> know is quite old) to get the following numbers :
>
> Since I was doing this on the same machine, with completely different builds
> (not simply a compile upgrade, but a full install), I figure it doesn't
> really matter what kind of machine it is, but just for grins, it is a Dual
> Opteron with 2GB of memory in it, compiled with the i386 confs.
>
> The 7.0 is compiled with the ULE scheduler...
>
> The following are averages of at least 5 runs :
>
> FreeBSD 5.4 - CPU 112,721 - MEM - 146,483
> FreeBSD 7.0 - CPU 177,339 - MEM - 95,920
>
> Now, I really don't know exactly what the ubench program is doing, but I
> think the description says that it is doing random integer and floating point
> operations for the CPU tests, and random memory allocation and copying for
> the memory test.
>
> So, can we explain the difference???? It looks like the latest SMP code
> allows it to process more operations, but what happened to the memory
> operations????
>
> Just to get an idea of what this was going to do to my scripts, I tried some
> benchmarks for those as well.
>
> I tried to run a PHP script using php 4.4.7 and got the following results :
>
> Using "time php index.php" to get the real time :
>
> FreeBSD 5.4 - 0.290 seconds
> FreeBSD 7.0 - 0.335 seconds
>
> So, do the slower memory operations cause that difference in the real time it
> takes to run that script???
>
> Thanks,
>
> Tim.
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to
> "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Tim Traver
In reply to this post by Alfred Perlstein-2
Alfred Perlstein wrote:

> Hey Tim, please try a later version of FreeBSD 7, there's been
> many improvements in the malloc(3) code since 7.0 so these
> results aren't very meaningful.
>
> Can you let us know what you see with 7-stable?
>
> thanks,
> -Alfred
>
>
>  
Alfred,

Thanks for responding, but I was using the 7.0 stable source that I
checked out about a week and a half ago...Is that not the current???

Tim.

> * Tim Traver <[hidden email]> [080812 14:39] wrote:
>  
>> Hi All,
>>
>> 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...
>>
>> I tried to get as many ducks in a row before posting this, cause i don't
>> want to waste any of the developers precious time, but I can't guarantee
>> that my methods were not flawed.
>>
>> For simplicity, I used a port called ubench (the latest version 0.3,
>> which I know is quite old) to get the following numbers :
>>
>> Since I was doing this on the same machine, with completely different
>> builds (not simply a compile upgrade, but a full install), I figure it
>> doesn't really matter what kind of machine it is, but just for grins, it
>> is a Dual Opteron with 2GB of memory in it, compiled with the i386 confs.
>>
>> The 7.0 is compiled with the ULE scheduler...
>>
>> The following are averages of at least 5 runs :
>>
>> FreeBSD 5.4 - CPU 112,721 - MEM - 146,483
>> FreeBSD 7.0 - CPU 177,339 - MEM - 95,920
>>
>> Now, I really don't know exactly what the ubench program is doing, but I
>> think the description says that it is doing random integer and floating
>> point operations for the CPU tests, and random memory allocation and
>> copying for the memory test.
>>
>> So, can we explain the difference???? It looks like the latest SMP code
>> allows it to process more operations, but what happened to the memory
>> operations????
>>
>> Just to get an idea of what this was going to do to my scripts, I tried
>> some benchmarks for those as well.
>>
>> I tried to run a PHP script using php 4.4.7 and got the following results :
>>
>> Using "time php index.php" to get the real time :
>>
>> FreeBSD 5.4 - 0.290 seconds
>> FreeBSD 7.0 - 0.335 seconds
>>
>> So, do the slower memory operations cause that difference in the real
>> time it takes to run that script???
>>
>> Thanks,
>>
>> Tim.
>>
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
>> To unsubscribe, send any mail to
>> "[hidden email]"
>>    
>
>  
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Tim Traver
In reply to this post by Robert N. M. Watson-2


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,

Yes, I agree, there are a lot of moving variables.

1) I did try the 4BSD scheduler too, and found that it was actually much
worse. It may be because the ubench will spawn a few processes, and ULE
is better at SMP than 4BSD is, but I don't know...

2) Unfortunately, I have now already replaced the 5.4 machines with 7.0.
I tried to take the benchmarks before I rebuilt things. Like I said, I'm
sure my methods were flawed...

These were both compiled with the 32 bit code...

Is there anything that I can do on this latest 7.0 box that might be
useful information???

Thanks,

Tim.


>>
>> I tried to get as many ducks in a row before posting this, cause i
>> don't want to waste any of the developers precious time, but I can't
>> guarantee that my methods were not flawed.
>>
>> For simplicity, I used a port called ubench (the latest version 0.3,
>> which I know is quite old) to get the following numbers :
>>
>> Since I was doing this on the same machine, with completely different
>> builds (not simply a compile upgrade, but a full install), I figure
>> it doesn't really matter what kind of machine it is, but just for
>> grins, it is a Dual Opteron with 2GB of memory in it, compiled with
>> the i386 confs.
>>
>> The 7.0 is compiled with the ULE scheduler...
>>
>> The following are averages of at least 5 runs :
>>
>> FreeBSD 5.4 - CPU 112,721 - MEM - 146,483
>> FreeBSD 7.0 - CPU 177,339 - MEM - 95,920
>>
>> Now, I really don't know exactly what the ubench program is doing,
>> but I think the description says that it is doing random integer and
>> floating point operations for the CPU tests, and random memory
>> allocation and copying for the memory test.
>>
>> So, can we explain the difference???? It looks like the latest SMP
>> code allows it to process more operations, but what happened to the
>> memory operations????
>>
>> Just to get an idea of what this was going to do to my scripts, I
>> tried some benchmarks for those as well.
>>
>> I tried to run a PHP script using php 4.4.7 and got the following
>> results :
>>
>> Using "time php index.php" to get the real time :
>>
>> FreeBSD 5.4 - 0.290 seconds
>> FreeBSD 7.0 - 0.335 seconds
>>
>> So, do the slower memory operations cause that difference in the real
>> time it takes to run that script???
>>
>> Thanks,
>>
>> Tim.
>>
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
>> To unsubscribe, send any mail to
>> "[hidden email]"
>>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Kris Kennaway-3
Tim Traver wrote:

> Is there anything that I can do on this latest 7.0 box that might be
> useful information???

Someone will need to repeat this under controlled conditions.  It's
quite a surprising result.

Kris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Tim Traver


Kris Kennaway wrote:
> Tim Traver wrote:
>
>> Is there anything that I can do on this latest 7.0 box that might be
>> useful information???
>
> Someone will need to repeat this under controlled conditions.  It's
> quite a surprising result.
>
> Kris
Kris,

If you can outline a procedure for me, I might be able to do these tests
for you, as I still have the 5.4 disk available.

Couple of things though...I'm not sure what code base the 5.4 box had on
it...I could maybe update the src and recompile the kernel.

I would probably have to have someone else take a look at exactly what
ubench is doing, and if it is indeed a test that makes sense to
use...anyone?

Once I am finished, I would assume you would need things like dmesg
output, the compiling conf parameters, etc...tell me what would be good...

If this is not controlled enough, then you might have to have one of the
performance team do it I guess...

Let me know,

Tim.



> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to
> "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Kris Kennaway-3
Tim Traver wrote:

>
> Kris Kennaway wrote:
>> Tim Traver wrote:
>>
>>> Is there anything that I can do on this latest 7.0 box that might be
>>> useful information???
>> Someone will need to repeat this under controlled conditions.  It's
>> quite a surprising result.
>>
>> Kris
> Kris,
>
> If you can outline a procedure for me, I might be able to do these tests
> for you, as I still have the 5.4 disk available.
>
> Couple of things though...I'm not sure what code base the 5.4 box had on
> it...I could maybe update the src and recompile the kernel.
>
> I would probably have to have someone else take a look at exactly what
> ubench is doing, and if it is indeed a test that makes sense to
> use...anyone?
>
> Once I am finished, I would assume you would need things like dmesg
> output, the compiling conf parameters, etc...tell me what would be good...
>
> If this is not controlled enough, then you might have to have one of the
> performance team do it I guess...
>

Robert outlined the steps that need to be done to begin with.

Kris
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Tim Traver
In reply to this post by Robert N. M. Watson-2


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 ????

Tim.









_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Kris Kennaway-3
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Tim Traver
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.


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Kris Kennaway-3
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Jason Evans-2
In reply to this post by Kris Kennaway-3
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 7.0 CPU and Memory Performance

Martin Cracauer
In reply to this post by Tim Traver
Tim Traver wrote on Tue, Aug 12, 2008 at 01:32:57PM -0700:
>
> For simplicity, I used a port called ubench (the latest version 0.3,
> which I know is quite old) to get the following numbers :

ubench is just another useless artificial benchmark with no base in
reality.  I forgot the specifics but last time I looked into what
exactly it is doing I threw it out instantly.  

If you really need to know I might be able to dig up some old notes
from the time, or maybe I bashed it publically somewhere.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <[hidden email]>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"