m_tag, malloc vs uma

[Karim Fodil-Lemelin]

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.