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>