On Tue, 26 Sep 2000, Ingo Molnar wrote:
> > Test of 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 + vmfixes-B2-deadlock.patch
>
> note that this is effectively test9-pre7 (with a couple of more fixes and
> the new multiqueue stuff), so you might want to test that as well.
Hi,
have tried the same test (mem=8M, make bzImage on UP-box) with vanilla
2.4.0-t9p7. Seems to work for me too: no VM-problems (deadlock, fatal OOM)
after more than 10h of heavy paging. X-3.3.6 apparently has no problems
either, although far from being useable with mem=8M.
However, there is one thing I've changed besides using t9p7: to save
my disk the swap partition on another disk on the second IDE-channel was
used instead of the one on the first, where all mounted ext2-fs's are.
Hence I might have benefit due to some parallel IO. But I believe the
deadlocks happened within the paging code path, thus the parallel access
to the normal fs for .c/.o/tmp rw wouldn't help. Rereading flushed pages
from gcc-binaries on /usr/bin may have relaxed the stress to some extend.
The total time for make bzImage however was not reduced significantly.
BTW, some numbers about scalability - using make bzImage of t9p7 with
identical .config on fresh-booted box as some kind of benchmark:
mem= total duration max. swap used kswapd-time CPU-idle
128M 10 min 0 0 0%
32M 11 min 5M 1 sec <5% (but peaks)
16M 32 min 20M 45 sec osz. 40+-30%
8M 6.5 h 13M 28 min 75% (+-20%)
These numbers must not be over-interpreted - just to give an idea.
Regards
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
