From owner-cvs-src@FreeBSD.ORG Tue Feb 17 20:52:51 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 4366D16A4DC; Tue, 17 Feb 2004 20:52:51 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A200043D2D; Tue, 17 Feb 2004 20:52:50 -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 i1I4qknJ036078; Tue, 17 Feb 2004 21:52:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2004 21:52:44 -0700 (MST) Message-Id: <20040217.215244.10296236.imp@bsdimp.com> To: mux@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040217075421.GF35475@elvis.mu.org> References: <20040216214602.GD35475@elvis.mu.org> <20040216.174604.89900183.imp@bsdimp.com> <20040217075421.GF35475@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: Wed, 18 Feb 2004 04:52:51 -0000 In message: <20040217075421.GF35475@elvis.mu.org> Maxime Henrion writes: : M. Warner Losh wrote: : > 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. : : 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. Ummm, I still don't see what it buys you over M_NOWAIT. You are going to do something when it fails. And there's really no good argument for malloc(bignum) in the kernel. People that do that will be better served by using some other interface to the kernel. Warner