dbench scalability testing

[Anton Blanchard]

Hi,

> I am starting with 2.2. to get more of a baseline to compare the 2.4
> improvements to.  That and to get some standard tests developed.

Sounds good.

> Thank you for the suggestions, now are these changes good for getting
> reliable results only, or also for improving performance?

The changes increase the amount of RAM that can be used for dirty buffers,
and so with 2G RAM I can run dbench 60 without touching the disk. :)
The changes will only work on 2.4.

If it doesnt touch the disk, I can get dbench runs which are less then 1%
apart. When it does touch the disk, things are slightly less repeatable.

> Do you have any other changes you implement for performance testing?

The changes are mainly for PPC (the only quad cpu machine we have here is
a PPC :) I have a readprofile that was hacked by tridge to do instruction
level accounting of the standard profiling data. This has been quite useful.

If you kill -STOP kupdated for the duration of the test, then the background
task of flushing old dirty buffers will not happen. Another way of achieving
this is to increase the relevant value in /proc/sys/vm/bdflush.

> If not, then we can get some.  Suggestions?  I will have to look into what we
> have (the lab is still in the last parts of the install phase so I don't have
> a solid handle on the various hardware platforms yet).

My test setup uses acenics. I have 2 PPCs and one ultrasparc and connect
two of them back to back and use smbtorture to approximate a netbench run.

Real netbench runs will be useful now because tridge tells me smbtorture
has not been verified to approximate netbench at the higher end of the
scale.

Anton