From owner-freebsd-arch Wed Jan 22 15:55:28 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2430737B401; Wed, 22 Jan 2003 15:55:27 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 290CA43ED8; Wed, 22 Jan 2003 15:55:26 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h0MNtPro026938 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 22 Jan 2003 18:55:25 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h0MNtKi90857; Wed, 22 Jan 2003 18:55:20 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15919.12136.371483.838009@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 18:55:20 -0500 (EST) To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: M_ flags summary. In-Reply-To: References: <15919.4208.394911.712558@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin writes: > > On 22-Jan-2003 Andrew Gallatin wrote: > > > > > > If we want to catch sleepable allocation bugs right up front, I > > suggest we put this: > > > > if (!(flags & M_NOWAIT)) { > > WITNESS_SLEEP(1, NULL); > > } > > > > at the top of malloc, and at the top of all entry points to the mbuf > > allocator. Eg, before the system has a chance to pull the allocation > > off of some cache which will succeed 99.5% of the time, except when > > the system is under memory pressure. > > We already do this for malloc(), that is the source of most of the > 'could sleep' messages these days. I have some patches I need to > commit to make the actual message more informative so that it will > say 'could malloc' etc. Actually, I think we do it only for small mallocs where we go through uma_zalloc{_arg}(). The case where size > KMEM_ZMAX does not (immediately) go through uma_zalloc(), so I was was worried things could sneek by. I'd feel more comfortable if the check happened in malloc() itself, so that both large and small cases got equal coverage. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message