From owner-freebsd-scsi@FreeBSD.ORG  Sun Jan 18 14:57:20 2004
Return-Path: <owner-freebsd-scsi@FreeBSD.ORG>
Delivered-To: freebsd-scsi@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 <dillon@apollo.backplane.com>
Message-Id: <200401182257.i0IMv63i097663@apollo.backplane.com>
To: Scott Long <scottl@freebsd.org>, freebsd-hackers@freebsd.org,
	Paul Twohey <twohey@CS.Stanford.EDU>, scsi@freebsd.org
References: <Pine.LNX.4.44.0401161607260.26554-100000@Xenon.Stanford.EDU>
	<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-scsi@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: SCSI subsystem <freebsd-scsi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
	<mailto:freebsd-scsi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-scsi>
List-Post: <mailto:freebsd-scsi@freebsd.org>
List-Help: <mailto:freebsd-scsi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
	<mailto:freebsd-scsi-request@freebsd.org?subject=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 
					<dillon@backplane.com>