>
>The machine I ran these tests on has a 133 MHz Cyrix CPU, 64M of ram,
>and IDE disks. I dont know if it makes any difference, but the mozilla
>source is on my /dev/hdc6 partition but the object and library files are
>on a /dev/hda3 which is (obviously) on a different disk.
>
>Hope someone finds this interesting/useful.
The thing we really need to do (once we get it stable - Ingo seems to
have finally found the reason for the "access past end" trouble) is to
tune the heuristics and the bdflush parameters for the new setup.
What happened was that a lot of the VM behaviour has changed quite
radically: we used to never be able to have more dirty buffers than
"real" buffers, and that's no longer true - it' actually quite common to
have more dirty buffers than you have buffer-space because there are
lots of "secondary" dirty buffers that are attached to the page cache.
Changes like that completely confused some of the previous logic in
bdflush, and it wrote things out (or left things not written out) at the
wrong time. I basically rewrote much of it, but I rewrote it so that
itwould _work_, not so that it would necessarily do the best possible
job performance-wise.
One parameter you can play around with is the "ndirty" parameter to
bdflush (it's the second number in /proc/sys/vm/bdflush) - try making it
twice as large (and/or half the size), and see if that makes any
difference. (It may not make much of a difference - I suspect that we
really need to change some of the code in bdflush() to make it do the
right thing).
That said, compiles should not make that large a difference for the new
code. There isn't all that much read-modify-write behaviour, and in the
absense of that the major win in the new code is just the much improved
SMP scalability. Which wouldn't help you ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/