Date: Tue, 3 Apr 2001 12:05:27 -0700 From: Alfred Perlstein <alfred@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: Garrett Rooney <rooneg@electricjellyfish.net>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c Message-ID: <20010403120527.H813@fw.wintelcom.net> In-Reply-To: <200104031813.f33ID4b58965@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 03, 2001 at 11:13:04AM -0700 References: <200104030315.f333FCX69312@freefall.freebsd.org> <20010403140457.B2952@electricjellyfish.net> <200104031813.f33ID4b58965@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010403 11:13] wrote: > > :On Mon, Apr 02, 2001 at 08:15:12PM -0700, Alfred Perlstein wrote: > :> alfred 2001/04/02 20:15:12 PDT > :> > :> Modified files: > :> sys/sys mbuf.h > :> sys/kern uipc_mbuf.c > :> Log: > :> Use only one mutex for the entire mbuf subsystem. > : > :I can see how this makes some things cheaper by allowing you to only lock a > :single mutex instead of several, but doesn't it also limit you to only a > :single thread using the mbuf subsystem at a time? Since mbufs are used in a > :fairly large number of places throught the system, wouldn't that be bad? > : > :I'm sure this has been thought through, I'm just trying to understand why this > :will be better in the long run. Isn't the goal to have fine grained locking, > :rather than single locks limiting access to subsystems? > : > :-- > :garrett rooney Unix was not designed to stop you from > > What about using the BSDI hash-table-of-mutexes idea? Where mutex > functionality is overloaded to some degree for any given subsystem. > This gives us sufficient parallelism without polluting system structures > with their own mutexes. For the allocator subsystems I plan on doing per CPU pools. I have the code written but not really tested: http://people.freebsd.org/~alfred/memcache/ -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010403120527.H813>