From owner-cvs-all Tue Apr 3 12: 5:39 2001 Delivered-To: cvs-all@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E825D37B71A; Tue, 3 Apr 2001 12:05:29 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f33J5RV07619; Tue, 3 Apr 2001 12:05:27 -0700 (PDT) Date: Tue, 3 Apr 2001 12:05:27 -0700 From: Alfred Perlstein To: Matt Dillon Cc: Garrett Rooney , 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> References: <200104030315.f333FCX69312@freefall.freebsd.org> <20010403140457.B2952@electricjellyfish.net> <200104031813.f33ID4b58965@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104031813.f33ID4b58965@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 03, 2001 at 11:13:04AM -0700 X-all-your-base: are belong to us. Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [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