From owner-freebsd-hackers Tue Nov 27 14:59:21 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id C9E0837B416 for ; Tue, 27 Nov 2001 14:59:17 -0800 (PST) Received: from onyx (onyx.cs.binghamton.edu [128.226.140.171]) by bingnet2.cc.binghamton.edu (8.11.6/8.11.6) with ESMTP id fARMx3q04381; Tue, 27 Nov 2001 17:59:03 -0500 (EST) Date: Tue, 27 Nov 2001 17:57:21 -0500 (EST) From: Zhihui Zhang X-Sender: zzhang@onyx To: freebsd-hackers@freebsd.org, xgalleri@enition.com Subject: Possible vmopar bug? (was malloc deadlock with M_NOWAIT) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG VM gurus: This seems to be bug! This morning I sent an email (attached below) regarding a hang at the "vmopar" state. While waiting for responses, I use Google Advanced Groups Search looking for "vmopar" in all FreeBSD archived mailing lists and I did find the following message posted by Xavier Galleri early this year (Sorry for this long URL line): http://groups.google.com/groups?selm=3A71C39F.8060109_enition.com%40ns.sol.net&output=gplain I run his program following his instructions in README file and the process indeed hangs just as he described: 10459 root -18 0 868K 436K vmopar 0:00 0.00% 0.00% mytest The file system intensive operation I used is (he suggested using tar): find /usr/src -name "*.c" -exec grep "hello" /dev/null {} \; After the process is stuck in "vmopar", I can not even use "reboot" to boot the system. This seems to be a bug in the VM system (I am using 4.4-Release). I hope some one can track this down. In this case, two different people (Xavier Galleri and me) can hang the system with different programs. I think it is worth investigation. --------------------------------------------------------------------------- My original email sent this morning follows: I am trying to allocate a dynamic number of large memory (128K) by malloc(128K, M_xxx, M_NOWAIT). Although this is not done in an interrupt routine, I figure I'd better use M_NOWAIT so that I can deal with the situation when the memory is low. However, I experience the following deadlock: #1 0xc02d8f4d in vm_object_page_remove (object=0xc03fa060, start=5690, end=5722, clean_only=0) at ../../vm/vm_object.c:1459 #2 0xc02d53ce in vm_map_delete (map=0xc03f9ee0, start=3243479040, end=3243610112) at ../../vm/vm_map.c:1872 #3 0xc02d35e3 in kmem_malloc (map=0xc03f9ee0, size=131072, flags=1) at ../../vm/vm_kern.c:365 #4 0xc01baed7 in malloc (size=131072, type=0xc0f6ab60, flags=1) at ../../kern/kern_malloc.c:188 The process that calls mallocs() hangs at the following statement inside vm_object_page_remove(): vm_page_sleep_busy(p, TRUE, "vmopar") At the same time, the entire system also freezes. I am wondering if I am doing the right thing here. Maybe 128K is too large for such a use? I am using 4.4-Release. Thanks for any help. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message