From owner-freebsd-current@FreeBSD.ORG Sun Jan 25 09:24:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEE41065676 for ; Sun, 25 Jan 2009 09:24:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 874AD8FC22 for ; Sun, 25 Jan 2009 09:24:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1E4B124D0; Sun, 25 Jan 2009 01:24:48 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BB4002D6004; Sun, 25 Jan 2009 01:24:47 -0800 (PST) Message-ID: <497C2FE3.6050304@elischer.org> Date: Sun, 25 Jan 2009 01:24:51 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alfred Perlstein References: <20090123154336.GJ60948@e.0x20.net> <200901232337.05627.hselasky@c2i.net> <200901240952.21670.hselasky@c2i.net> <20090125003010.GY87077@elvis.mu.org> <20090125085405.GA87077@elvis.mu.org> In-Reply-To: <20090125085405.GA87077@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 09:24:49 -0000 Alfred Perlstein wrote: > * Maksim Yevmenkin [090124 17:33] wrote: >> On Sat, Jan 24, 2009 at 4:30 PM, Alfred Perlstein wrote: >>> From a purely academic standpoint... why can't netgraph use >>> standard mutexes? >>> >>> Is there a pointer you can give me? >> well, its not that netgraph can not use mutexes at all. its just that >> there has to be an understanding between all subsystems that interact >> with netgraph. its just like Julian said, everybody has to play nice >> and ensure that control is given back to netgraph as soon as possible. >> netgraph thread can not be de-scheduled for too long because the same >> thread services other nodes. in fact, there are other netgraph nodes >> that use mutexes, there is no way around it. the only rule is that >> mutexes have to be used prudently. if there is a guarantee that every >> single code path that is called from netgraph context is "safe" (i.e. >> any mutexes that are touched in the code path are guaranteed to not >> cause de-scheduling of netgraph thread for any significant amount of >> time) then everything is fine. >> >> in any case, i really do hope that the patch that i send to Hans >> Petter today (you were cc'd) is something that we all can agree on. > > FWIW, with the exception of Giant, all normal mutexes have this > guarantee. Giant actually sort of has this guarantee, however it > may be held for long periods of _activity_. > > You can't "block" with a mutex, hence you'll never be behind > a sleeping process, only a running process or tandem of running > processes. > well there is blocking and there is blocking.. if you block on a thread that is going to switch two pointers atomically then that is ok as this si not going to harm throughput of netgraph as a whole. If you block for a thread that is allocating memory, and re-arange the routing table or something large like that, you can really screw up netgraph's thoughput as yo are blocking a thread that ahs to do work in other places too and because your node has blocked it, other nodes are getting starved. See my mail to arch on this topic.. I'm suggesting that there be a flag for mutexes that label them as a 'leaf' mutex. By which I mean the mutex 'call graph' will never see thes as anything as a terminal node. Netgraph has no problems with using mutexes in this way, but getting on a chain of mutexes some of which may take a while to clear ca totally screw it's usefulness.