From owner-cvs-src@FreeBSD.ORG  Mon Feb 16 23:54:22 2004
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 18FDF16A4CE; Mon, 16 Feb 2004 23:54:22 -0800 (PST)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1230A43D1F; Mon, 16 Feb 2004 23:54:22 -0800 (PST)
	(envelope-from mux@freebsd.org)
Received: by elvis.mu.org (Postfix, from userid 1920)
	id E232A5C748; Mon, 16 Feb 2004 23:54:21 -0800 (PST)
Date: Tue, 17 Feb 2004 08:54:21 +0100
From: Maxime Henrion <mux@freebsd.org>
To: "M. Warner Losh" <imp@bsdimp.com>
Message-ID: <20040217075421.GF35475@elvis.mu.org>
References: <20040216210503.GC35475@elvis.mu.org>
	<20040216.142540.32721629.imp@bsdimp.com>
	<20040216214602.GD35475@elvis.mu.org>
	<20040216.174604.89900183.imp@bsdimp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040216.174604.89900183.imp@bsdimp.com>
User-Agent: Mutt/1.4.1i
cc: src-committers@FreeBSD.org
cc: cvs-src@FreeBSD.org
cc: scottl@FreeBSD.org
cc: cvs-all@FreeBSD.org
cc: phk@phk.freebsd.dk
cc: rwatson@FreeBSD.org
cc: des@FreeBSD.org
Subject: Re: cvs commit: src/sys/vm vm_kern.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2004 07:54:22 -0000

M. Warner Losh wrote:
> In message: <20040216214602.GD35475@elvis.mu.org>
>             Maxime Henrion <mux@FreeBSD.org> writes:
> : > How would that be different than M_NOWAIT and then trying again a
> : > couple of times?  Each time will fail if it is too big.  And that's
> : > not meaningfully distinguishable from there not being enough memory
> : > currently available to satisfy the request.
> : 
> : Because if there is a memory shortage but it's possible to get the
> : requested amount of memory later (because it's smaller than kmem_map),
> : M_WAITOK | M_SAFE won't fail but wait while M_NOWAIT will fail right
> : away.  Why trying again when we already have a flag for this?  What this
> : patch does is allow to call malloc(verybignumber) without crashing to
> : help in cases where it's hard to define what's a reasonable size.
> 
> It seems of dubious value then.  If someone is going to call malloc
> with a verybignumber by mistake, they are just as likely to neglect to
> put M_SAFE in place.

Yes, but at least with M_SAFE there is a proper way to handle this
without enforcing artificial limits...  There's no way to make this work
without the author of the code doing something about it, otherwise we'll
end up changing the M_WAITOK semantics.  And we badly don't want to do
that -- which is why this thread started.

Cheers,
Maxime