On Mon, 25 Sep 2000, Martin Diehl wrote:
> PS: vmfixes-2.4.0-test9-B2 not yet tested - will do later.
Hi - done now:
using 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 I ended up with the box
deadlocked again! Was "make bzImage" on UP booted with mem=8M.
After about 4 hours at load 2-3 and almost continously paging the box
is apparently locked up. SysRq+t still shows several processes including
kswapd being scheduled "current" (one after the other of course).
Mem-Info (retyped from SysRq+m):
Active: 847 / inactive dirty: 67 / inactive clean: 0 / free: 64
2x16 + 1x32 + 1x64 + 1x128 = 256kB
Swap cache: add 3353996, delete 3353209, find 2300336/9605753
Free swap: 496144kB
2048 pages of RAM
0 pages of HIGHMEM
490 reserved pages
74 pages shared
787 pages cached
0 pages in page table cache
Buffer memory: 236kB
No change on this at all, despite the scheduling activity still observed.
I've looked up several EIP-values (given by SysRq+p) vs. System.map to get
an idea what is still going on. The functions I've recorded (this # often):
page_launder(10)
try_to_free_buffer(5)
deactivate_page_nolock(4)
refill_inactive_scan(3)
nr_free_pages(1)
wakeup_kswapd(1)
__wake_up(1)
kmem_cache_reap(1)
sys_fstatfs(1)
sys_statfs(1)
The results of this very rudimentary "profiling the deadlock" are far from
statistical significance of course. The only ordering rule implied in this
list is the number of occurences - i.e., I don't see any pattern or call
chain there.
Finally, SysRq+e solved the problem: hanging processes term'ed, VM
deadlock released, box seems to be as useable as after it was booted.
Comments?
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/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:14 EST