From owner-cvs-src@FreeBSD.ORG Mon Feb 16 16:46:10 2004 Return-Path: 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 DA4E116A4CE; Mon, 16 Feb 2004 16:46:10 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 625CA43D1D; Mon, 16 Feb 2004 16:46:10 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i1H0k6nJ007100; Mon, 16 Feb 2004 17:46:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 16 Feb 2004 17:46:04 -0700 (MST) Message-Id: <20040216.174604.89900183.imp@bsdimp.com> To: mux@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20040216214602.GD35475@elvis.mu.org> References: <20040216210503.GC35475@elvis.mu.org> <20040216.142540.32721629.imp@bsdimp.com> <20040216214602.GD35475@elvis.mu.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2004 00:46:11 -0000 In message: <20040216214602.GD35475@elvis.mu.org> Maxime Henrion 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. Warner