From owner-freebsd-hackers@FreeBSD.ORG Wed May 26 13:48:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AD4216A4CE for ; Wed, 26 May 2004 13:48:34 -0700 (PDT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E16D43D41 for ; Wed, 26 May 2004 13:48:34 -0700 (PDT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.9p2/8.12.9) with ESMTP id i4QKlfPK028776; Wed, 26 May 2004 15:47:41 -0500 (CDT) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.9p2/8.12.9/Submit) id i4QKlfOK028775; Wed, 26 May 2004 15:47:41 -0500 (CDT) (envelope-from tinguely) Date: Wed, 26 May 2004 15:47:41 -0500 (CDT) From: Mark Tinguely Message-Id: <200405262047.i4QKlfOK028775@casselton.net> To: bjohns123@msn.com, freebsd-hackers@freebsd.org In-Reply-To: X-Spam-Status: No, hits=0.9 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on ccn.casselton.net X-Mailman-Approved-At: Thu, 27 May 2004 04:50:55 -0700 Subject: Re: KVA space problems? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2004 20:48:34 -0000 This has been seen before and there is at least one open problem report that the kernel malloc() unexpectantly returns NULL in WAITOK situations. http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/53382 --- I think malloc returns before your patch, namely around line 199: va = (caddr_t) kmem_malloc(kmem_map, (vm_size_t)ctob(npg), flags ); if (va == NULL) { splx(s); return ((void *) NULL); } Although, I agree that the kernel malloc() should not do this, if KVM is depleted or fragmented to this point, I suspect your changes of simply retrying again will cause an infinite loop in malloc(). If malloc() sleeps waiting for KVM to be freed, my guess this will lead to the processes to hang for a long time if not forever. I think this because people are bumping the MBUFs numbers up and not changing the KVM size, once the KVM is depleted/fragmented it shouldn't come down for a long time. --- The pre 5.x VM assumes KVM will not be depleted. contigmalloc() used to leak physical pages if the KVM got depleted. I was told "the system will panic soon anyway, why put them back". --Mark Tinguely