Skip site navigation (1)Skip section navigation (2)
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>