Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Jun 2004 23:32:19 -0700 (PDT)
From:      Nate Lawson <nate@root.org>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern uipc_usrreq.c
Message-ID:  <20040611232939.F3249@root.org>
In-Reply-To: <20040611012513.GI78955@elvis.mu.org>
References:  <200406102134.i5ALYcNr004704@repoman.freebsd.org> <20040611012513.GI78955@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040611232939.F3249>