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