Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: Poor 2.3.8 times | Date | 23 Jun 1999 18:30:17 GMT |
| |
In article <19990622233114.A7510@sailboat.mis.uncwil.edu>, Jim Nance <jlnance@sailboat.mis.uncwil.edu> wrote:
> >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/
| |