From owner-cvs-src@FreeBSD.ORG  Sat Jun 12 06:32:37 2004
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8218816A4CE
	for <cvs-src@FreeBSD.org>; Sat, 12 Jun 2004 06:32:37 +0000 (GMT)
Received: from root.org (root.org [67.118.192.226])
	by mx1.FreeBSD.org (Postfix) with SMTP id 5A23543D46
	for <cvs-src@FreeBSD.org>; Sat, 12 Jun 2004 06:32:37 +0000 (GMT)
	(envelope-from nate@root.org)
Received: (qmail 3316 invoked by uid 1000); 12 Jun 2004 06:32:19 -0000
Date: Fri, 11 Jun 2004 23:32:19 -0700 (PDT)
From: Nate Lawson <nate@root.org>
To: Alfred Perlstein <alfred@freebsd.org>
In-Reply-To: <20040611012513.GI78955@elvis.mu.org>
Message-ID: <20040611232939.F3249@root.org>
References: <200406102134.i5ALYcNr004704@repoman.freebsd.org>
 <20040611012513.GI78955@elvis.mu.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: Robert Watson <rwatson@FreeBSD.org>
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern uipc_usrreq.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Jun 2004 06:32:37 -0000

On Thu, 10 Jun 2004, Alfred Perlstein wrote:
> * Robert Watson <rwatson@FreeBSD.org> [040610 14:34] wrote:
> >   - Sam's version of this change, as with the BSD/OS version, made use of
> >     both a global lock and per-unpcb locks.  However, in practice, the
> >     global lock covered all accesses, so I have simplified out the unpcb
> >     locks in the interest of getting this merged faster (reducing the
> >     overhead but not sacrificing granularity in most cases).  We will want
> >     to explore possibilities for improving lock granularity in this code in
> >     the future.
>
> I noticed this in the BSD/os version, it was sort of like...
> "the global lock covers everything, what's the point of the
> underlying locks..?"

In my conversation with the BSD/OS guys, there were often cases where they
went with a more global lock within a subsystem versus untangling
re-entrant paths, which would be needed for finer-grained locking.  This
was true for the CAM approach they used where a single mutex per device
instance and a middle layer lock protected queue handling.

-Nate