From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 18:55:20 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 111E11065674 for ; Fri, 10 Apr 2009 18:55:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E251C8FC12 for ; Fri, 10 Apr 2009 18:55:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9E4AF46B8A; Fri, 10 Apr 2009 14:55:19 -0400 (EDT) Date: Fri, 10 Apr 2009 19:55:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Karim Fodil-Lemelin In-Reply-To: <49DF5F75.6080607@xiplink.com> Message-ID: References: <49DF5F75.6080607@xiplink.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 18:55:20 -0000 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