From owner-freebsd-current@FreeBSD.ORG Sun Mar 20 04:19:13 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24D7716A4CF for ; Sun, 20 Mar 2005 04:19:13 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AA6D43D1D for ; Sun, 20 Mar 2005 04:19:12 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from gothmog.gr (patr530-b225.otenet.gr [212.205.244.233]) j2K4IcNF023438 for ; Sun, 20 Mar 2005 06:18:41 +0200 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j2K4J8Du020858 for ; Sun, 20 Mar 2005 06:19:08 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j2JM8O4A011790 for freebsd-current@freebsd.org; Sun, 20 Mar 2005 00:08:24 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Sun, 20 Mar 2005 00:08:24 +0200 From: Giorgos Keramidas To: freebsd-current@freebsd.org Message-ID: <20050319220824.GA11339@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Forced M_NOWAIT in uma_core.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2005 04:19:13 -0000 While stress testing a program with a few thousand threads on a current system today (FreeBSD 6.0-CURRENT #1: Sat Mar 19 08:40:58 EET 2005), the following came up on my console: % malloc(M_WAITOK) of "16", forcing M_NOWAIT with the following non-sleepable locks held: % exclusive sleep mutex UMA lock r = 0 (0xc0761f20) locked @ /usr/src/sys/vm/uma_core.c:1498 % KDB: stack backtrace: % kdb_backtrace(1,1,1,10,c14454e0) at kdb_backtrace+0x29 % witness_warn(5,0,c06a897b,c0689d86,c051fb39) at witness_warn+0x19a % uma_zalloc_arg(c14454e0,0,102) at uma_zalloc_arg+0x41 % malloc(10,c06e7320,102,10,c06e7320) at malloc+0xae % free_unr(c1d60b40,18ae1,c259fcf0,c259a200,c25427e0) at free_unr+0x2f % thread_fini(c259fcf0,16c) at thread_fini+0x33 % zone_drain(c1445900) at zone_drain+0x170 % zone_foreach(c0618cb0,d46c0cfc,c062a5fa,c069825c,246) at zone_foreach+0x37 % uma_reclaim(c069825c,246,0,d46c0c90,c052168c) at uma_reclaim+0x12 % vm_pageout_scan(0,c07623c0,0,c06aaa6e,5c3) at vm_pageout_scan+0xfe % vm_pageout(0,d46c0d48,0,c062b3c4,0) at vm_pageout+0x2c3 % fork_exit(c062b3c4,0,d46c0d48) at fork_exit+0xa4 % fork_trampoline() at fork_trampoline+0x8 % --- trap 0x1, eip = 0, esp = 0xd46c0d7c, ebp = 0 --- Is this a known issue of uma_core.c?