From owner-freebsd-arch Thu Jan 23 4:27: 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 CCDAC37B401; Thu, 23 Jan 2003 04:27:06 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A229E43EB2; Thu, 23 Jan 2003 04:27:05 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NCQlBs036638; Thu, 23 Jan 2003 12:26:47 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h0NCQht8051348; Thu, 23 Jan 2003 12:26:43 GMT (envelope-from dfr@nlsystems.com) Subject: Re: M_ flags summary. From: Doug Rabson To: John Baldwin Cc: Andrew Gallatin , arch@FreeBSD.ORG In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1043324803.28337.40.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Jan 2003 12:26:43 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05 version=2.41 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 Wed, 2003-01-22 at 21:58, John Baldwin wrote: > 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. I was thinking yesterday that perhaps it would be useful to have a new entry point to the allocator. This might be called mmalloc, with the idea that mmalloc is to malloc as msleep is to tsleep. The caller would call it with its currently held mutex as an argument and that mutex would filter all the way down to the place where malloc sleeps and be passed to msleep (or something). This makes it explicit for the caller what is happening, i.e. it is clear that as a side effect of calling the allocator, your mutex may be released and regained so you need to take care about any cached results depending on variables which might be modified by other threads. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message