From owner-cvs-all Tue Apr 3 18:11:26 2001 Delivered-To: cvs-all@freebsd.org Received: from technokratis.com (modemcable092.3-201-24.mtl.mc.videotron.ca [24.201.3.92]) by hub.freebsd.org (Postfix) with ESMTP id B02BE37B71C; Tue, 3 Apr 2001 18:11:19 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f341Cu516380; Tue, 3 Apr 2001 21:12:56 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 3 Apr 2001 21:12:56 -0400 From: Bosko Milekic To: Matt Dillon Cc: Alfred Perlstein , 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: <20010403211256.A16192@technokratis.com> References: <200104030315.f333FCX69312@freefall.freebsd.org> <20010403140457.B2952@electricjellyfish.net> <200104031813.f33ID4b58965@earth.backplane.com> <20010403194004.A15434@technokratis.com> <200104040020.f340Kgi74269@earth.backplane.com> <20010403173529.O12164@fw.wintelcom.net> <200104040045.f340jCW75337@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: <200104040045.f340jCW75337@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 03, 2001 at 05:45:12PM -0700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 03, 2001 at 05:45:12PM -0700, Matt Dillon wrote: > :> require any (mutex) locking at all? This solves the contention problem > :> and the interrupt problem. > : > :While this is a good idea, it doesn't give us a consistant view of > :the stats without additional atomic ops or critical regions. > : > :-- > :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > Good god, don't waste time trying to optimize the statistics! If you > are worried, just make the stats counters per-cpu and have the > utilities add them up on the fly, and be done with it. No locking, no > locked instructions, no fuss, no muss. > > -Matt > Well, although the cmpexchg trick is cute, we're still faced with the problem of populating the free lists when we allocate from the map. There is also the problem of starvation where we need to cv_signal() to alert blockers that we have something for them. Clearly, you do handle the sleeping/allocation issue in your pseudo-code example (in the allocation code) but that `slow' version will likely have to grab a mutex to at least allocate from the map [see first paragraph] and if not, to block on a condition variable. If we omit locking while on our way to block on a cond. var., we are faced with race conditions where we may end up blocking even though something has become available in the meantime. Regards, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message