Date: Wed, 12 Mar 2014 22:46:59 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Garrett Wollman <wollman@freebsd.org> Subject: Re: kernel memory allocator: UMA or malloc? Message-ID: <20140313054659.GG32089@funkthat.com> In-Reply-To: <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca> References: <20140312062517.GX32089@funkthat.com> <1291887352.21761108.1394675980413.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140313054659.GG32089>