mbuma: network buffers & UMA
Andre Oppermann
andre at freebsd.org
Tue Mar 16 01:34:21 PST 2004
Bosko Milekic wrote:
>
> The post below has received exactly zero attention on the
> freebsd-current mailing list. I'm assuming this is because there are
> other exciting threads going on there right now, such as style debates
> and lovely feature requests. :-)
>
> I would like to commit this RSN. I need feedback from the Release
> Engineering people on how close we are to a RELEASE and if it's OK for
> me to break netstat -m stats for a few weeks or, if not, what the
> appropriate course of action is.
I haven't looked at the diff in detail (the largest part seems to be
the removal of subr_mbuf.c) but it sounds very exciting! I would love
to have a UMA based mbuf system in 5-CURRENT and 5.3R.
--
Andre
> Fellow earthlings,
>
> I would like to request some testing on diverse architectures of the
> following patch (~130K):
>
> http://people.freebsd.org/~bmilekic/code/mbuma-v2.diff
>
> In short, the above accomplishes several things and is the result of
> one of my now mature p4 repositories which I have been able to again
> address following a generous hardware donation.
>
> This basically gets rid of the existing mbuf allocator and replaces
> it with some routines which get hooked on top of UMA, the existing
> general-purpose SMP-friendly allocator in -CURRENT, after adding
> some extensions to UMA which hopefully make allocations faster than
> they would be without them.
>
> The current list of implications (whether good or bad is for you to
> decide):
>
> - NMBCLUSTERS, as a compile-time option, is now gone. The
> kern.ipc.nmbclusters tunable and sysctl still exist and are both
> read+write. Currently, the sysctl does not effect anything but
> will soon be made to allow for runtime (dynamic) modification of
> the maximum number of mbuf clusters allocatable cap. If you set
> the tunable to zero, though, the number of clusters allocatable is
> unbounded and the system will scale according to demand. Be
> careful... leaving these unbounded may not be what you really
> want.
>
> - Memory allocated to network buffers can (and now will) be
> reclaimed by UMA when required and, for example, after a large
> network spike.
>
> - Current on-par performance with the existing allocator. Soon some
> modifications to UMA that improve performance drastically in the
> common case may change that, though - for the better.
>
> - For developers: M_WAIT behavior now is the same as for all other
> UMA allocations, and is no longer special for network buffers.
>
> - Currently netstat(1) mbuf stats ('netstat -m') are broken and
> instead the following is displayed:
>
> fermat% netstat -m
> Mbuf statistics are currently unavailable via netstat(1), see
> UPDATING.
> This is only a TEMPORARY measure in -CURRENT.
> For current mbuf and cluster allocation stats, see sysctl vm.zone
>
> I don't plan to fix them prior to doing some other work (which may
> change the way stats work, anyway) in UMA. Hopefully this won't
> be too much of a problem for most of you.
>
> - So far has been very stable on my dual Athlon and a friend's x86
> UP machine (I think it's UP, anyway). Some other architectures,
> particular 64-bit ones, would be worth testing.
>
> - Some things (e.g., dev/nsp) I just noticed might be broken by the
> above changes due to slight time-delay between the vendor p4 branch
> and the CVS checked out repo I used to generate the final diff.
> If something you're using is broken by the diff, it is only broken
> slightly, and you'll notice it immediately during kernel compile,
> so you can fix it (it's generally just changing some includes) or
> Email it to me and I'll send you a custom diff. This only
> applies to the current diff posted above and will not be
> committed.
>
> That's all I could think of right now. I would like to commit this
> soon as I have other things in the pipeline that build on top of it.
> I should also mention that there are various other implications in
> addition to the above but are more relevant to the developer than the
> user, so they'll probably appear in a really large commit log.
>
> Reviews and constructive criticism is both welcomed and appreciated.
> Please leave me in the To: line - although I am subscribed to
> -current, I'd like to see feedback in my main box.
>
> Regards,
> --
> Bosko Milekic * bmilekic at technokratis.com * bmilekic at FreeBSD.org
> TECHNOkRATIS Consulting Services * http://www.technokratis.com/
>
> "It is impossible for anyone to begin to learn what he believes
> he already knows." -- Epictetus (c.a.d. 55-c135)
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
More information about the freebsd-arch
mailing list