Date: Tue, 3 Apr 2001 21:12:56 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Alfred Perlstein <alfred@FreeBSD.ORG>, 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: <20010403211256.A16192@technokratis.com> In-Reply-To: <200104040045.f340jCW75337@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 03, 2001 at 05:45:12PM -0700 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010403211256.A16192>