From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 13 05:47:01 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 22FFD527; Thu, 13 Mar 2014 05:47:01 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F41A47E8; Thu, 13 Mar 2014 05:47:00 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s2D5kxgL019088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Mar 2014 22:46:59 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s2D5kxVA019087; Wed, 12 Mar 2014 22:46:59 -0700 (PDT) (envelope-from jmg) Date: Wed, 12 Mar 2014 22:46:59 -0700 From: John-Mark Gurney To: Rick Macklem Subject: Re: kernel memory allocator: UMA or malloc? Message-ID: <20140313054659.GG32089@funkthat.com> Mail-Followup-To: Rick Macklem , Freebsd hackers list , Garrett Wollman References: <20140312062517.GX32089@funkthat.com> <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 12 Mar 2014 22:46:59 -0700 (PDT) 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 05:47:01 -0000 Rick Macklem wrote this message on Wed, Mar 12, 2014 at 21:59 -0400: > 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? >From my understanding, the malloc case is "slightly" slower as it needs to look up which bucket to use, but after the lookup, the buckets are UMA, so the performance will be the same... > 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 Hmm... I took a look at the code, and if you're stuck in btalloc, either pause(9) isn't working, or you're looping, which probably means you're really low on memory... > 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). Yeh, if you put additional alignment requirements, that's probably it, but if you needed these alignment requirements, how was malloc satisfying your request? > 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()? I'd say it depends upon how many and the number... If you're allocating many megabytes of memory, and the wastage is 50%+, then think about it, but if it's just a few objects, then the coding time and maintenance isn't worth it.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."