From owner-freebsd-hackers Mon Mar 1 11:45:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id 2C7EF150BD for ; Mon, 1 Mar 1999 11:45:31 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id LAA16503; Mon, 1 Mar 1999 11:40:46 -0800 (PST) Message-Id: <199903011940.LAA16503@implode.root.com> To: Luoqi Chen Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update In-reply-to: Your message of "Mon, 01 Mar 1999 14:34:50 EST." <199903011934.OAA23618@lor.watermarkgroup.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 01 Mar 1999 11:40:46 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> New bugs found ( and not fixed ): >> >> * exec_map can only hold 16 exec'ing processes at once. It needs a >> counter and a sleep/wait. >> >> Sometimes when I ran Matt J's 'breakit' script, a background program >> would 'Abort trap' out instantly on startup because more then 16 >> were doing an exec at once. This can only occur in a low-memory >> or heavy-I/O situation. >> >There could also be potential deadlocks when all 16 processes hold a lot in >exec_map and then all of them try to allocate more from exec_map (for loading >elf interpreter). The simplest solution is to use a separate map. Allocations from exec_map are done using kmem_alloc_wait() and frees are done using kmem_free_wakeup, so they already sleep/wakeup as appropriate when the map is full. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message