From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 19:32:02 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A61106573E for ; Fri, 10 Apr 2009 19:32:02 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) by mx1.freebsd.org (Postfix) with ESMTP id 731BE8FC22 for ; Fri, 10 Apr 2009 19:32:02 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from relay9.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 12BDE1E4834; Fri, 10 Apr 2009 15:32:02 -0400 (EDT) Received: by relay9.relay.iad.mlsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id AF6D11E44EB; Fri, 10 Apr 2009 15:32:01 -0400 (EDT) Message-ID: <49DF9EAD.1050609@xiplink.com> Date: Fri, 10 Apr 2009 15:31:57 -0400 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Robert Watson References: <49DF5F75.6080607@xiplink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: m_tag, malloc vs uma X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 19:32:04 -0000 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.