From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 19:46:15 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61E8106566B; Tue, 27 Jan 2009 19:46:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7E43E8FC1C; Tue, 27 Jan 2009 19:46:15 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n0RJUhV5005160; Tue, 27 Jan 2009 14:30:43 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Tue, 27 Jan 2009 14:30:43 -0500 (EST) Date: Tue, 27 Jan 2009 14:30:43 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <497F51D6.1000903@elischer.org> Message-ID: References: <23211.1232871523@critter.freebsd.dk> <497C249C.5060507@elischer.org> <497F51D6.1000903@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Poul-Henning Kamp , Robert Watson Subject: Re: need for another mutex type/flag? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2009 19:46:16 -0000 On Tue, 27 Jan 2009, Julian Elischer wrote: > Robert Watson wrote: >> On Sun, 25 Jan 2009, Julian Elischer wrote: >> >>> Even purely documentary would be good but given the option, I'd like it to >>> scream when Witness is enabled and you try get another mutex.... >>> >>> there are certain contexts (e.g. in most netgraph nodes) where we really >>> want the authors to only take such locks and taking more unpredictable >>> mutexes plays havoc with netgraph response times as a system as a whole, >>> since if one node blocks, teh thread doesn't get to go off and service >>> other nodes. >> >> I thought lots of Netgraph nodes liked to do things like call m_pullup() >> and m_prepend()? Disallowing acquiring mutexes will prevent them from >> doing that. > > I think I mentioned that in another mail. > The problem I see is that some module writers are tempted to > just use a mutex in their node without thinking about what the > result will be. My understanding is that the mbuf allocation > code has been tuned to within an inch of its life to try > keep it's waits to a minimum. I am worried about it, > but I am more worried about a netgraph node waiting on something > that is depending on some piece of hardware such as what I think > HPS had in his suggested patch for the bluetooth code.. I thought all you wanted to mandate that the netgraph code itself didn't nest any mutexes. If it doesn't hold any of its own mutexes while calling m_prepend(), etc, then is that still a problem? -- DE