From owner-freebsd-arch Wed Jan 22 13:58: 8 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 6158A37B401 for ; Wed, 22 Jan 2003 13:58:06 -0800 (PST) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98DE943F5F for ; Wed, 22 Jan 2003 13:58:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 19365 invoked from network); 22 Jan 2003 21:58:12 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Jan 2003 21:58:12 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h0MLw2UT039040; Wed, 22 Jan 2003 16:58:03 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15919.4208.394911.712558@grasshopper.cs.duke.edu> Date: Wed, 22 Jan 2003 16:58:05 -0500 (EST) From: John Baldwin To: Andrew Gallatin Subject: Re: M_ flags summary. Cc: arch@FreeBSD.ORG 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 On 22-Jan-2003 Andrew Gallatin wrote: > > > 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. 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message