m_tag, malloc vs uma
Robert Watson
rwatson at FreeBSD.org
Fri Apr 10 11:55:20 PDT 2009
On Fri, 10 Apr 2009, Karim Fodil-Lemelin wrote:
> Is there any plans on getting the mbuf tags sub-system integrated with the
> universal memory allocator? Getting tags for mbufs is still calling malloc
> in uipc_mbuf.c ... What would be the benefits of using uma instead?
Hi Karim:
Right now there are no specific plans for changes along these lines, although
we have talked about moving towards better support for deep objects in m_tags.
Right now, MAC requires a "deep" copy, because labels may be complex objects,
and this is special-cased in the m_tag code. One way to move in that
direction would be to move from an explicit m_tag free pointer to a pointer to
a vector of copy, free, etc, operations. This would make it easier to support
more flexible memory models there, rather than forcing the use of malloc(9).
That said, malloc(9) for "small" memory types is essentially a thin wrapper
accounting around a set of fixed-size UMA zones:
ITEM SIZE LIMIT USED FREE REQUESTS FAILURES
16: 16, 0, 3703, 966, 55930783, 0
32: 32, 0, 1455, 692, 30720298, 0
64: 64, 0, 4794, 1224, 38352819, 0
128: 128, 0, 3169, 341, 5705218, 0
256: 256, 0, 1565, 535, 48338889, 0
512: 512, 0, 386, 494, 9962475, 0
1024: 1024, 0, 66, 354, 3418306, 0
2048: 2048, 0, 314, 514, 29945, 0
4096: 4096, 0, 250, 279, 4567645, 0
For larger memory sizes, malloc(9) becomes instead a thin wrapper around VM
allocation of kernel address space and pages. So as long as you're using
smaller objects, malloc(9) actually offers most of the benefits of slab
allocation.
Because m_tag(9) is an interface used for a variety of base system and third
party parts, changes to the KPI would need to be made with a major FreeBSD
release -- for example with 8.0. Such a change is definitely not precluded at
this point, but in a couple of months we'll hit feature freeze and it won't be
possible to make those changes after that time.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-net
mailing list