Date: Tue, 3 Apr 2001 18:31:42 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Bosko Milekic <bmilekic@technokratis.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: <200104040131.f341VgS76589@earth.backplane.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> <20010403211256.A16192@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104040131.f341VgS76589>