From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 01:59:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E87A4A7; Thu, 13 Mar 2014 01:59:47 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 41E2E152; Thu, 13 Mar 2014 01:59:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEADMQIVODaFve/2dsb2JhbABWA4NBV4MGtyeGX0+BNHSCJQEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASHUAgNsUmhSxeBKYxcBgEBARokEAcRgl6BSQSVboQJkHuDSSExfAgXIg X-IronPort-AV: E=Sophos;i="4.97,642,1389762000"; d="scan'208";a="105114075" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 12 Mar 2014 21:59:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 67A32B3F47; Wed, 12 Mar 2014 21:59:40 -0400 (EDT) Date: Wed, 12 Mar 2014 21:59:40 -0400 (EDT) From: Rick Macklem To: John-Mark Gurney Message-ID: <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> In-Reply-To: <20140312062517.GX32089@funkthat.com> Subject: Re: kernel memory allocator: UMA or malloc? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: Freebsd hackers list , Garrett Wollman X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 01:59:47 -0000 John-Mark Gurney wrote: > Rick Macklem wrote this message on Tue, Mar 11, 2014 at 21:32 -0400: > > I've been working on a patch provided by wollman@, where > > he uses UMA instead of malloc() to allocate an iovec array > > for use by the NFS server's read. > > > > So, my question is: > > When is it preferable to use UMA(9) vs malloc(9) if the > > allocation is going to be a fixed size? > > UMA has benefits if the structure size is uniform and a non-power of > 2.. > In this case, it can pack the items more densely, say, a 192 byte > allocation can fit 21 allocations in a 4k page size verse malloc > which > would round it up to 256 bytes leaving only 16 per page... These > counts per page are probably different as UMA may keep some > information > in the page... > Ok, this one might apply. I need to look at the size. > It also has the benefit of being able to keep allocations "half > alive".. > "freed" objects can be partly initalized with references to buffers > and > other allocations still held by them... Then if the systems needs to > fully free your allocation, it can, and will call your function to > release these remaining resources... look at the ctor/dtor > uminit/fini > functions in uma(9) for more info... > > uma also allows you to set a hard limit on the number of allocations > the zone provides... > Yep. None of the above applies to this case, but thanks for the good points for a future case. (I've seen where this gets used for the "secondary zone" for mbufs+cluster.) > Hope this helps... > Yes, it did. Thanks. Does anyone know if there is a significant performance difference if the allocation is a power of 2 and the "half alive" cases don't apply? Thanks all for your help, rick ps: Garrett's patch switched to using a fixed size allocation and using UMA(9). Since I have found that a uma allocation request with M_WAITOK can get the thread stuck sleeping in "btalloc", I am a bit shy of using it when I've never had a problem with malloc(). Btw, this was for a pagesize cluster allocation, so it might be related to the alignment requirement (and running on a small i386, so the kernel address space is relatively small). I do see that switching to a fixed size allocation to cover the common case is a good idea, but I'm not sure if setting up a uma zone is worth the effort over malloc()? > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >