From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 6 00:27:47 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9CF616A401; Tue, 6 Mar 2007 00:27:47 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9917013C467; Tue, 6 Mar 2007 00:27:47 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 7E85C1A4D83; Mon, 5 Mar 2007 16:27:47 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BE000514E7; Mon, 5 Mar 2007 19:27:46 -0500 (EST) Date: Mon, 5 Mar 2007 19:27:46 -0500 From: Kris Kennaway To: Robert Watson Message-ID: <20070306002745.GA21890@xor.obsecurity.org> References: <20070304141136.GA4935@stud.fit.vutbr.cz> <20070306001251.N31701@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070306001251.N31701@fledge.watson.org> User-Agent: Mutt/1.4.2.2i Cc: Divacky Roman , hackers@freebsd.org, kris@FreeBSD.org Subject: Re: investigation of Giant usage in kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2007 00:27:47 -0000 On Tue, Mar 06, 2007 at 12:15:56AM +0000, Robert Watson wrote: > On Sun, 4 Mar 2007, Divacky Roman wrote: > > >I looked at where Giant is held in the kernel and I found these > >interesting things: > > > >1) in fs/fifofs/fifo_vnops.c we lock Giant when calling > >sorecieve()/sosend() this is a bandaid for fixing a race that doesnt have > >to exist anymore. ie. it needs some testing and can be remvoed > > Hmm. I think that conclusion is a bit premature. Per our conversation on > IRC, the workaround was added back prior to a release due to our being > unable to resolve a very difficult to debug race condition. There is no > evidence the race doesn't exist anymore: what is needed is testing to > determine if it does or not. The race condition occurred under high make > -j load on SMP; FYI, make uses a fifo to implement a concurrency limiting > token scheme in order to bound total simultaneous jobs despite many make > instances running. > > I've CC'd Kris since I know that he was able to reproduce the problem, so > might be able to provide advice on how to do so. It was probably the big package dispatch makefile, which is an enormous (20MB) makefile with all of the dependency ordering data for the entire ports tree, which is used to dispatch builds in t he correct order using make -j${LARGENUM}, where that is typically 60 or so depending on the size of the client pool. In addition about half a dozen or more of these things might be running at any one time. Kris