From owner-freebsd-arch Thu Jan 23 7:40: 5 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 65A8837B40B for ; Thu, 23 Jan 2003 07:39:58 -0800 (PST) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id C67E543E4A for ; Thu, 23 Jan 2003 07:39:57 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 25401 invoked from network); 23 Jan 2003 15:40:00 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Jan 2003 15:40:00 -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 h0NFdtUT041493; Thu, 23 Jan 2003 10:39:56 -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: <1043324803.28337.40.camel@builder02.qubesoft.com> Date: Thu, 23 Jan 2003 10:39:59 -0500 (EST) From: John Baldwin To: Doug Rabson Subject: Re: M_ flags summary. Cc: arch@FreeBSD.ORG, Andrew Gallatin 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 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. 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. -- 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