From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 6 00:15:57 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 6E55016A401; Tue, 6 Mar 2007 00:15:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 48B4E13C4AC; Tue, 6 Mar 2007 00:15:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AEFE1470F9; Mon, 5 Mar 2007 19:15:56 -0500 (EST) Date: Tue, 6 Mar 2007 00:15:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Divacky Roman In-Reply-To: <20070304141136.GA4935@stud.fit.vutbr.cz> Message-ID: <20070306001251.N31701@fledge.watson.org> References: <20070304141136.GA4935@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kris@FreeBSD.org, hackers@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:15:57 -0000 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. Robert N M Watson Computer Laboratory University of Cambridge