Robert Watson wrote:
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
Hi Robert,
Thank you for the answer, clear and concise. I asked the question
because I had modified pf_get_mtag() to use uma directly in the hope
that it would be faster then calling malloc. But since pf_mtag is
20bytes, malloc will end up using a fixed 32bytes zone and I shouldn't
expect much speed gain from using something like (except some savings
from not having to select the 32bytes zone):
extern uma_zone_t pf_mtag_zone;
static __inline struct pf_mtag *
pf_get_mtag(struct mbuf *m)
{
struct m_tag *mtag;
if ((mtag = m_tag_find(m, PACKET_TAG_PF, NULL)) == NULL) {
mtag = uma_zalloc(pf_mtag_zone, M_NOWAIT);
if (mtag == NULL)
return (NULL);
m_tag_setup(mtag, MTAG_ABI_COMPAT, PACKET_TAG_PF, sizeof(struct
pf_mtag));
mtag->m_tag_free = pf_mtag_delete;
bzero(mtag + 1, sizeof(struct pf_mtag));
m_tag_prepend(m, mtag);
}
return ((struct pf_mtag *)(mtag + 1));
}
Where pf_mtag_delete is a wrapper around uma_zfree().
Regards,
Karim.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
