Messages in this thread |  | | Date | Mon, 25 Sep 2000 12:40:16 +0200 (CEST) | From | Martin Diehl <> | Subject | Re: more testing on 2.4.0-t9p[456] VM deadlocks |
| |
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/
|  |