Date: Sat, 12 Jun 2004 00:40:56 -0600 From: Scott Long <scottl@freebsd.org> To: Nate Lawson <nate@root.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern uipc_usrreq.c Message-ID: <40CAA578.2060808@freebsd.org> In-Reply-To: <20040611232939.F3249@root.org> References: <200406102134.i5ALYcNr004704@repoman.freebsd.org> <20040611012513.GI78955@elvis.mu.org> <20040611232939.F3249@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote: > 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 Yes, but as this approach was described to me, I'm not terribly sure that it would work in an environment with multiple SIMs. I appreciate their approach of 'medium-grain locking' a lot, but I question whether their approach to CAM and to network locking was really sufficient. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40CAA578.2060808>