From owner-cvs-all Tue Apr 3 18:31:51 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D5E0B37B724; Tue, 3 Apr 2001 18:31:43 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f341VgS76589; Tue, 3 Apr 2001 18:31:42 -0700 (PDT) (envelope-from dillon) Date: Tue, 3 Apr 2001 18:31:42 -0700 (PDT) From: Matt Dillon Message-Id: <200104040131.f341VgS76589@earth.backplane.com> To: Bosko Milekic 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 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> <20010403211256.A16192@technokratis.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : 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 I don't think this is an issue. It doesn't matter if something has become available on the per-cpu list between the time we check it and the time we do the slow allocation. The fact of the matter is that the per-cpu list is obviously starved for mbufs at that point and even if something does become available, you almost certainly want to do the slow allocation anyway (if not this time, it would happen the next time ... so you might as well do it this time). You are not going to improve performance by covering that particular race condition. In fact, you will reduce performance. The slow allocation needs to grab a lock, but the whole point is that it would rarely get called anyhow so for the slow allocation you just don't care whether there is massive contention or not. It's not worth optimizing the slow-pool. The slow allocation could be implemented in one of several ways. The easiest is to pull a block of mbufs (like four or five) off the global pool and add the mbufs to the per-cpu freelist (using the same cmpexg trick), and then simply loop back up to the top and 'retry' the allocation from the per-cpu list. In that way if you are also using a per-cpu counter to manage the number of mbufs on the freelist, you can handle any race condition that might have occured (i.e. there might now be 'too many' mbufs on the freelist). Personally speaking I don't think you have to be that paranoid. The whole purpose of the per-cpu freelist is to handle the 'active' mbuf dataset.... the per-cpu freelist should not ever be used to manage the system's entire mbuf pool, just the working set. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message