Date: Mon, 30 Oct 2000 23:31:30 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: David Greenman <dg@root.com> Cc: Bosko Milekic <bmilekic@dsuper.net>, freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <200010310731.e9V7VUJ16831@earth.backplane.com> References: <200010301927.LAA01623@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> I recently wrote an initial "scratch pad" design for per-CPU mbuf
:> lists (in the MP case). The design consists simply of introducing
:> these "fast" lists for each CPU and populating them with mbufs on bootup.
:> Allocations from these lists would not need to be protected with a mutex
:> as each CPU has its own. The general mmbfree list remains, and remains
:> protected with a mutex, in case the per-CPU list is empty.
:
: I have only one question - is the lock overhead really so high that this
:is needed?
:
:-DG
:
:David Greenman
The biggest benefit to per-cpu allocation pools is L1-cache locality,
though being able to avoid locking can also be significant if you are
doing lots of small allocations.
However, the schemes that I see implemented today by Linux, for example,
and Dynix too (as Terry pointed out) are actually considerably more
complex then we really need. If those schemes can reap a 95% cache
hit I would argue that implementing a simpler scheme that only reaps
85% might be better for us.
For example, to reap most of the benefit we could simply implement a
5-10 slot 'quick cache' (also known as a working-set cache) in
MALLOC()/FREE() and zalloc[i]()/zfree(). It is not necessary to keep
big per-cpu pools. With small per-cpu pools and hystersis we reap most
of the benefits but don't have to deal with any of the garbage collection
or balancing issues. After seeing the hell the Linux folks are going
through, I'd much prefer to avoid having to deal with balancing.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010310731.e9V7VUJ16831>