Date: Tue, 31 Oct 2000 00:29:53 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Bosko Milekic <bmilekic@dsuper.net> Cc: Mike Smith <msmith@mass.osd.bsdi.com>, freebsd-net@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <20001031002953.O22110@fw.wintelcom.net> In-Reply-To: <Pine.BSF.4.21.0010301822100.31430-100000@jehovah.technokratis.com>; from bmilekic@dsuper.net on Mon, Oct 30, 2000 at 07:19:19PM -0500 References: <200010302240.e9UMeWF18172@mass.osd.bsdi.com> <Pine.BSF.4.21.0010301822100.31430-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bosko Milekic <bmilekic@dsuper.net> [001030 16:14] wrote: > > (2) If you are allocating mbufs and have 0 on your fastlist you aquire > (lw) mbufs from the general pool into your fast list. > > Alfred's added suggestion: Keep mbufs in mmbfree classed as "chunks" > (i.e. of (lw) number of mbufs, for example). > > The new design drops this idea completely. First of all, let's say that > we do consider (2), then we would have to go through a costly count of > the mbufs in the mmbfree list every time we're doing the transfer. The > suggestion above says that we should keep the mbufs in chunks, to make > the transfer less costly, but it's flawed, because in that case, there > are two possibilities: > > (1) all "chunks" have same size, (lw); this is unreasonable because > (lw) is tunable and can change. > > (2) "chunks" have various sizes depending on when (lw) changes, one > should be combining smaller chunks into larger ones (and vice versa?) > in those cases; this is unreasonable because it will add too much > overhead into some of those allocations. I'd rather deal with not > having (2) at all and keep the speed than deal with this case. > > Of course, this isn't set in stone, and I'd like to know from those > who will argue, if any, that (2) should still be implemented, why it is > necessary. (1) alone will eliminate ping-pong effects. Actually this might work. :) Consider, you're at 0 buffers on your freelist, you allocate a chunk from the general pool if it's bigger than the tunable 'lw' the whole chain goes onto your 'lw' list. As you allocate and free from lw, it will 'spill' onto your 'hw' list because that's where you free to when 'lw' is full. If you happen to grab something off the freelist smaller than 'lw' you just live with that, or possibly grab another chunk, either way this algorithm heals the chunks by spilling free's from lw to hw to make the cutoff. Eventually you'll overflow your hw list and free the correct sized chunk onto the freelist (hw - lw buffers). If you're just consuming mbufs well then someone else will be doing the above described free'ing balancing out the main pool. Remeber, accuracy with balancing the chunks isn't nearly as important as speed. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001031002953.O22110>