Messages in this thread Patch in this message | | | Date | Mon, 25 Sep 2000 01:54:30 +0200 (CEST) | From | Martin Diehl <> | Subject | more testing on 2.4.0-t9p[456] VM deadlocks |
| |
Hi,
want to summarize my observations wrt the VM-deadlock issue. Everything tested on UP box bootet with mem=8M and 500M swap.
2.4.0-t9p4 (vanilla) deadlocks almost everywhere (even in initscripts!), simple dd with large enough bs deadlock's as soon as page_out should start - i.e. no swapspace ever used. Fortunately, deadlock can be cured by SysRq+e.
2.4.0-t9p5+vmfixes-2.4.0-test9-A1 much better, but still some deadlock. Much harder to trigger in a reproducible way. "make dep" on /usr/src/linux seems to be a good candidate, initscripts too. At some time some (undetermined) process hangs - this process remains the only one ever being current forever! However EIP still changes according to SysRq+p. This behaviour can not be solved by SysRq+[ekil]. SysRq+[sb] not succesful either, so its time for unclean reboot und fsck (which deadlocks too).
2.4.0-t9p6 (vanilla) very similar to last one. Put some printk() into it to find out, it ends up looping forever due to goto try_again in __alloc_pages(). Just to give it a try I've added a counter to it restricting the number of retries (to some arbitrary number - 5 in may case). If this is reached I continue to the code following the goto. result: no "deadlocks" anymore! I was even able to run the initscripts and make bzImage. However, from time to time some processes were killed due to lack of memory. sysctl/overcommit_memory was 0 and there was plenty of free swapspace. Finally I followed Ingo' suggestion to change __GFP_IO to __GFP_WAIT in refill_inactive(). With this there was no process killed anymore! I was able to complete make bzImage without anything going wrong. Furthermore it was possible to start X and login to KDE - although the system performance was far from being useable there was no problem (besides disk activity). The box run at av. load 2 for several hours doing almost nothing but page_in/out. My try_again escape was hit quit often (several 1000 times) but the fallback to the critical case seems to work. As I printk()'ed the value of memory_pressure in this case I can tell the box was running at memory_pressure of 30000-40000 for more than 5 hours with peaks beyond 50000 when starting X/KDE e.g. - just in case these numbers tell you something.
Taken together, the described fix seems to do the job on my system. The patch vs. vanilla 2.4.0-t9p6 is included below. I would not claim it to be "Right" or even more than a hack to find out what's going wrong. Just want to give you some feedback.
PS: vmfixes-2.4.0-test9-B2 not yet tested - will do later.
Regards Martin
diff -Nur linux-2.4.0-t9p6.orig/mm/page_alloc.c linux-2.4.0-t9p6/mm/page_alloc.c --- linux-2.4.0-t9p6.orig/mm/page_alloc.c Mon Sep 25 01:08:52 2000 +++ linux-2.4.0-t9p6/mm/page_alloc.c Mon Sep 25 01:16:50 2000 @@ -295,6 +295,7 @@ int direct_reclaim = 0; unsigned int gfp_mask = zonelist->gfp_mask; struct page * page = NULL; + int retry = 5; /* * Allocations put pressure on the VM subsystem. @@ -444,9 +445,14 @@ * processes, etc). */ if (gfp_mask & __GFP_WAIT) { - try_to_free_pages(gfp_mask); - memory_pressure++; - goto try_again; + if (--retry > 0) { + try_to_free_pages(gfp_mask); + memory_pressure++; + goto try_again; + } + printk(KERN_CRIT "critical memory fallback\n"); + printk("%s - memory_pressure = %i\n", + __FUNCTION__, memory_pressure); } } diff -Nur linux-2.4.0-t9p6.orig/mm/vmscan.c linux-2.4.0-t9p6/mm/vmscan.c --- linux-2.4.0-t9p6.orig/mm/vmscan.c Mon Sep 25 01:08:40 2000 +++ linux-2.4.0-t9p6/mm/vmscan.c Sun Sep 24 13:14:14 2000 @@ -891,7 +891,7 @@ do { made_progress = 0; - if (current->need_resched && (gfp_mask & __GFP_IO)) { + if (current->need_resched && (gfp_mask & __GFP_WAIT)) { __set_current_state(TASK_RUNNING); schedule(); } - 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/
| |