From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 14:57:20 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 6B76016A4CE; Sun, 18 Jan 2004 14:57:20 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9349343D54; Sun, 18 Jan 2004 14:57:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0IMv682097664; Sun, 18 Jan 2004 14:57:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0IMv63i097663; Sun, 18 Jan 2004 14:57:06 -0800 (PST) (envelope-from dillon) Date: Sun, 18 Jan 2004 14:57:06 -0800 (PST) From: Matthew Dillon Message-Id: <200401182257.i0IMv63i097663@apollo.backplane.com> To: Scott Long , freebsd-hackers@freebsd.org, Paul Twohey , scsi@freebsd.org References: <20040118160802.GC32115@FreeBSD.org.ua> <200401181844.i0IIivlQ096389@apollo.backplane.com> <400AE3AB.1070102@freebsd.org> <200401181957.i0IJvFTe096883@apollo.backplane.com> <200401182238.i0IMcQYZ097543@apollo.backplane.com> Subject: Re: [CHECKER] bugs in FreeBSD 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: Sun, 18 Jan 2004 22:57:20 -0000 : M_NOWAIT is being used pretty much as if it were M_WAITOK|M_USE_RESERVE : most of the time, especially considering the side effect situation when : such allocations fail. I don't think M_WAITOK|M_USE_RESERVE would be : any less reliable, actually. It looks like the whole paradigm has : shifted away from the original definition of M_NOWAIT to something that : is more like a cross between M_NOWAIT, M_WAITOK, and M_USE_RESERVE. oops, don't take that literally. M_USE_RESERVE means something else. M_NOWAIT is triggering VM_ALLOC_INTERRUPT which is allowed to dig into the free (vm) page reserve. Another interesting thing I've found, and correct me if I'm wrong, but it looks like when the 5.x slab allocator allocates M_NOWAIT memory that newly allocated zone becomes available for normal M_WAITOK allocations as well. This is something DFly's slab allocator does too (I have a big XXX comment for it), and the 4.x allocator too I think. That could create an exhaustion issue. -Matt Matthew Dillon