Date: Fri, 10 Apr 2009 19:55:19 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Karim Fodil-Lemelin <kfl@xiplink.com> Cc: freebsd-net@freebsd.org Subject: Re: m_tag, malloc vs uma Message-ID: <alpine.BSF.2.00.0904101950350.36143@fledge.watson.org> In-Reply-To: <49DF5F75.6080607@xiplink.com> References: <49DF5F75.6080607@xiplink.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904101950350.36143>