Messages in this thread |  | | Date | Wed, 27 Sep 2000 16:27:45 +0200 (CEST) | From | Martin Diehl <> | Subject | Re: 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.
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |