From owner-freebsd-arch Thu Jan 23 8:36: 6 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 C2F9F37B401; Thu, 23 Jan 2003 08:36:03 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6643243F13; Thu, 23 Jan 2003 08:36:02 -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 h0NGZeBs039699; Thu, 23 Jan 2003 16:35:40 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 h0NGZct8056861; Thu, 23 Jan 2003 16:35:40 GMT (envelope-from dfr@nlsystems.com) Subject: Re: M_ flags summary. From: Doug Rabson To: John Baldwin Cc: arch@FreeBSD.org, Andrew Gallatin In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1043339738.29341.1.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 23 Jan 2003 16:35:38 +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 Thu, 2003-01-23 at 15:39, John Baldwin wrote: > On 23-Jan-2003 Doug Rabson wrote: > > 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. > > This would prevent the malloc implementation from using internal mutexes > that it msleep's or cv_wait's on. You only get to pass in one mutex > to cv_wait* and msleep. That did occur to me too, which was why I wrote "or something". It looks hard to DTRT here without a version of msleep which took a list of mutexes to release. > In my experience, one can often "fix" problems > with holding locks across malloc() by malloc()'ing things earlier in the > function before you need locks. This is obviously preferable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message