From owner-freebsd-arch Wed Jan 22 13:43:25 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 CACA437B401 for ; Wed, 22 Jan 2003 13:43:23 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B36A43ED8 for ; Wed, 22 Jan 2003 13:43:23 -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 h0MLhHro018192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 22 Jan 2003 16:43:17 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h0MLhCv90749; Wed, 22 Jan 2003 16:43:12 -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.4208.394911.712558@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 16:43:12 -0500 (EST) To: arch@FreeBSD.ORG Subject: Re: M_ flags summary. In-Reply-To: <20030122155457.A77036@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> 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 Speaking as the token 3rd party driver vendor, the removal of M_WAITOK/M_TRYWAIT is irritating, but not something that can't be solved with yet another ifdef in my driver. Breaking the 5.0 ABI prior to 5.1 is no big deal to me, as I don't plan to support 5.0-RELEASE anyway, so I don't care what the #defines end up as in the 5.0-STABLE branch. My thoughts are that whether we pronounce it po-ta-to, or po-tat-o, its still a potato and how its pronounced doesn't matter nearly as much as how it tastes. The taste "problem" here is that it always used to be safe to sleep in a process context. That's not true anymore. Now its safe to sleep in a process context if you're not holding any mutexes. So there are pleny of sleepable allocation bugs lurking. 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. Sorry for dragging this in another direction.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message