[lkml]   [2000]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: more testing on 2.4.0-t9p[456] VM deadlocks

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.


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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.021 / U:14.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site