VM benchmarks

VM benchmarks

[Nick Piggin]

After playing with the active / inactive list balancing a bit,
I found I can very consistently take 2-3 seconds off a non
swapping kbuild, and the light swapping case is closer to 2.4.
Heavy swapping case is better again. Lost a bit in the middle
though.

http://www.kerneltrap.org/~npiggin/vm/4/

At the end of this I might come up with something that is very
suited to kbuild and no good at anything else. Do you have any
other ideas of what I should test?

Nick

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Andrew Morton]

Nick Piggin <piggin@cyberone.com.au> wrote:
>
> After playing with the active / inactive list balancing a bit,
> I found I can very consistently take 2-3 seconds off a non
> swapping kbuild, and the light swapping case is closer to 2.4.
> Heavy swapping case is better again. Lost a bit in the middle
> though.
> 
> http://www.kerneltrap.org/~npiggin/vm/4/
> 
> At the end of this I might come up with something that is very
> suited to kbuild and no good at anything else. Do you have any
> other ideas of what I should test?
> 

The thing people most seem to complain about is big compilations.

Things like a bitkeeper consistency check while dinking with the X UI have
also been noted, but that's a bit hard to quantify.

Maybe ask Roger to try his efax workload?


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Nick Piggin]

Andrew Morton wrote:

>Nick Piggin <piggin@cyberone.com.au> wrote:
>
>>After playing with the active / inactive list balancing a bit,
>>I found I can very consistently take 2-3 seconds off a non
>>swapping kbuild, and the light swapping case is closer to 2.4.
>>Heavy swapping case is better again. Lost a bit in the middle
>>though.
>>
>>http://www.kerneltrap.org/~npiggin/vm/4/
>>
>>At the end of this I might come up with something that is very
>>suited to kbuild and no good at anything else. Do you have any
>>other ideas of what I should test?
>>
>>
>
>The thing people most seem to complain about is big compilations.
>
>Things like a bitkeeper consistency check while dinking with the X UI have
>also been noted, but that's a bit hard to quantify.
>
>Maybe ask Roger to try his efax workload?
>
>
>

efax is a compilation as well. I would be up for trying it, but it
needs quite a lot of GUI dev libraries installed to compile it.
I'll get onto it sometime I suppose, but for now I'll try to leave
my test box unchanged.

Unfortunately starting mozilla / kde / openoffice is another one
people complain about but harder to test...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Martin J. Bligh]

> efax is a compilation as well. I would be up for trying it, but it
> needs quite a lot of GUI dev libraries installed to compile it.
> I'll get onto it sometime I suppose, but for now I'll try to leave
> my test box unchanged.
> 
> Unfortunately starting mozilla / kde / openoffice is another one
> people complain about but harder to test...

Maybe you could just get gentoo to compile the whole distro ;-)

What kind of parallelism are you putting into make?

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Nick Piggin]

Martin J. Bligh wrote:

>>efax is a compilation as well. I would be up for trying it, but it
>>needs quite a lot of GUI dev libraries installed to compile it.
>>I'll get onto it sometime I suppose, but for now I'll try to leave
>>my test box unchanged.
>>
>>Unfortunately starting mozilla / kde / openoffice is another one
>>people complain about but harder to test...
>>
>
>Maybe you could just get gentoo to compile the whole distro ;-)
>
>What kind of parallelism are you putting into make?
>
>


On the graph here: http://www.kerneltrap.org/~npiggin/vm/4/
the x axis is the -j factor, and I'm compiling a 2.4.21
source with gcc 3.3 booting with mem=64M.

You can see it just starts to swap at -j6 and I'm going up
to -j16 which is then fairly heavy swapping (takes >20minutes).

Another thing that will need looking at is non swapping
pagecache performance of course.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Roger Luethi]

On Mon, 02 Feb 2004 11:11:46 +1100, Nick Piggin wrote:
> efax is a compilation as well. I would be up for trying it, but it

The main advantage of efax over kbuild is that it is completely immune
to unfairness. And it used to have a low variance (in 2.4). Other than
that, access patterns are similar enough to make me suspect that gcc
loads are all quite similar.

> needs quite a lot of GUI dev libraries installed to compile it.
>
> I'll get onto it sometime I suppose, but for now I'll try to leave
> my test box unchanged.

You can actually do something like which shouldn't require the
dependencies on the test box:

/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.3/cc1plus -fpreprocessed efaxi586.ii \
-quiet -O2 -Wall -fexceptions -frtti -fsigned-char -fno-check-new -o main.s

All you need is the preprocessed code.


I can test a couple of patches I you care, though. Which ones?

Roger
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Nick Piggin]

Roger Luethi wrote:

>On Mon, 02 Feb 2004 11:11:46 +1100, Nick Piggin wrote:
>
>>efax is a compilation as well. I would be up for trying it, but it
>>
>
>The main advantage of efax over kbuild is that it is completely immune
>to unfairness. And it used to have a low variance (in 2.4). Other than
>that, access patterns are similar enough to make me suspect that gcc
>loads are all quite similar.
>
>
>>needs quite a lot of GUI dev libraries installed to compile it.
>>
>>I'll get onto it sometime I suppose, but for now I'll try to leave
>>my test box unchanged.
>>
>
>You can actually do something like which shouldn't require the
>dependencies on the test box:
>
>/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.3/cc1plus -fpreprocessed efaxi586.ii \
>-quiet -O2 -Wall -fexceptions -frtti -fsigned-char -fno-check-new -o main.s
>
>

Could you zip up the preprocessed file and send it to me if possible
please? (off list of course)

>All you need is the preprocessed code.
>
>
>I can test a couple of patches I you care, though. Which ones?
>
>

I have 3 patches here http://www.kerneltrap.org/~npiggin/vm/
that should apply in order. If you apply to the -mm tree, please
back out the rss limit patch first.

If you can test them it would be good.

I would be interested in soon looking at some of your patches in
combination with these.

Nick
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Roger Luethi]

On Tue, 03 Feb 2004 10:17:57 +1100, Nick Piggin wrote:
> I have 3 patches here http://www.kerneltrap.org/~npiggin/vm/
> that should apply in order. If you apply to the -mm tree, please
> back out the rss limit patch first.
> 
> If you can test them it would be good.

I added results for all 3 patches of yours combined (2.6.1 patched)
and for the reversal patch I posted (2.6.0 revert). Clear improvements
for compiling. Might be interesting to test the patches individually,
but I will likely be unable to conduct further tests til next week. Let
me know if there are any tests you are specifically interested in,
and I will do more testing when I get back.

Roger

kbuild (make -j 24, 64 MB system)
		avg
2.4.21		120     101  107  110  112  114  116  128  134  135  143
2.4.23		140.4   116  118  124  125  132  150  153  157  161  168
2.4.25-pre6	161.8   141  145  148  153  155  156  169  173  185  193
pre6-rmap15l	441.8   274  383  387  439  462  464  468  492  500  549
2.6.0		513     387  446  493  498  512  512  546  550  592  594
2.6.1 patched	351.6   304  312  334  345  349  357  359  361  392  403
2.6.0 revert	441     375  408  409  425  429  437  454  461  487  525

efax (one large compile process, 32 MB system)
		avg
2.4.21		237.5   234  234  235  236  238  238  238  239  240  243
2.4.23		228.8   227  227  228  229  229  229  229  230  230  230
2.4.25-pre6	229.2   227  228  228  228  229  229  229  230  230  234
pre6-rmap15l	362.7   350  360  362  363  364  364  364  364  367  369
2.6.0		842.9   805  816  833  837  842  842  843  864  871  876
2.6.1 patched	508.3   477  501  511  511  512  513  513  513  516  516
2.6.0 revert	587.7   534  542  545  547  551  570  607  645  646  690

qsbench (-p 4 -m 96, 256 MB system)
		avg
2.4.21		222.3   214  217  218  218  219  219  222  229  231  236
2.4.21		221.1   214  216  216  218  219  220  223  224  229  232
2.4.23		223.8   219  220  221  223  223  223  223  225  230  231
2.4.25-pre6	217.2   208  209  210  212  213  213  223  224  226  234
pre6-rmap15l	1261.3 1171 1241 1253 1254 1268 1272 1274 1288 1293 1299
2.6.0		329.3   253  279  281  286  300  355  371  374  388  406
2.6.1 patched	336.8   272  275  277  301  304  375  376  383  383  422
2.6.0 revert	340     302  310  310  315  323  331  352  354  389  414
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Nick Piggin]

Roger Luethi wrote:

>On Tue, 03 Feb 2004 10:17:57 +1100, Nick Piggin wrote:
>
>>I have 3 patches here http://www.kerneltrap.org/~npiggin/vm/
>>that should apply in order. If you apply to the -mm tree, please
>>back out the rss limit patch first.
>>
>>If you can test them it would be good.
>>
>
>I added results for all 3 patches of yours combined (2.6.1 patched)
>and for the reversal patch I posted (2.6.0 revert). Clear improvements
>for compiling. Might be interesting to test the patches individually,
>but I will likely be unable to conduct further tests til next week. Let
>me know if there are any tests you are specifically interested in,
>and I will do more testing when I get back.
>
>

Thanks Roger,
Hmm results aren't bad... although the active/inactive balance
tuning you see here: http://www.kerneltrap.org/~npiggin/vm/4/
isn't included (you're testing the green kernel)

If I can get things a bit more into shape today I'll post another
patchset.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Koni]

It seems to me that increasing -jX doesn't necessarily result in a
linear increase in load since the kernel build process has all kinds of
dependencies and source files distributed in different nested
subdirectories. Thus, it may not be possible for make to spawn X gcc
instances say unless there are at least X independent files to compile
in the directory it's working in. Maybe something about kbuild that I
don't know, I just use make bzImage.

Perhaps it doesn't matter, from the graphs its obvious that you were
able to get the VM to thrash by raising the -jX parameter. Anyway, my
suggestion for something else to test would be to generate a contrived
build where all the source files are in the same directory and the
makefile has no dependencies, just a .c.o rule and a list of files. That
might remove some noise from the -jX variable. Perhaps the efax compile
is more like this, I don't know. Just a thought... might make it easier
to see the effects of small tweaks.

Cheers,
Koni

On Sun, 2004-02-01 at 18:36, Nick Piggin wrote:
> After playing with the active / inactive list balancing a bit,
> I found I can very consistently take 2-3 seconds off a non
> swapping kbuild, and the light swapping case is closer to 2.4.
> Heavy swapping case is better again. Lost a bit in the middle
> though.
> 
> http://www.kerneltrap.org/~npiggin/vm/4/
> 
> At the end of this I might come up with something that is very
> suited to kbuild and no good at anything else. Do you have any
> other ideas of what I should test?
> 
> Nick
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: VM benchmarks

[Martin J. Bligh]

> It seems to me that increasing -jX doesn't necessarily result in a
> linear increase in load since the kernel build process has all kinds of
> dependencies and source files distributed in different nested
> subdirectories. Thus, it may not be possible for make to spawn X gcc
> instances say unless there are at least X independent files to compile
> in the directory it's working in. Maybe something about kbuild that I
> don't know, I just use make bzImage.

A full -j on the kernel spawns about 1300 processes constantly on a 16-way,
so there's not too much of a problem there. Make sure you do "make vmlinux"
not "make bzImage" though, as the compression phase is all single-threaded.
There's also a pretty much single-threaded linker phase at the end, which
is unavoidable, but on the whole it scales pretty well.

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>