Date: Tue, 21 Sep 2010 09:20:00 +0300 From: Andriy Gapon <avg@freebsd.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: Andre Oppermann <andre@freebsd.org>, Jeff Roberson <jeff@freebsd.org>, Robert Watson <rwatson@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: zfs + uma Message-ID: <4C984E90.60507@freebsd.org> In-Reply-To: <4C95CCDA.7010007@freebsd.org> References: <4C93236B.4050906@freebsd.org> <4C935F56.4030903@freebsd.org> <alpine.BSF.2.00.1009181221560.86826@fledge.watson.org> <alpine.BSF.2.00.1009181135430.23448@desktop> <4C95C804.1010701@freebsd.org> <alpine.BSF.2.00.1009182225050.23448@desktop> <4C95CCDA.7010007@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 19/09/2010 11:42 Andriy Gapon said the following: > on 19/09/2010 11:27 Jeff Roberson said the following: >> I don't like this because even with very large buffers you can still have high >> enough turnover to require per-cpu caching. Kip specifically added UMA support >> to address this issue in zfs. If you have allocations which don't require >> per-cpu caching and are very large why even use UMA? > > Good point. > Right now I am running with 4 items/bucket limit for items larger than 32KB. But I also have two counter-points actually :) 1. Uniformity. E.g. you can handle all ZFS I/O buffers via the same mechanism regardless of buffer size. 2. (Open)Solaris does that for a while and it seems to suit them well. Not saying that they are perfect, or the best, or an example to follow, but still that means quite a bit (for me). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C984E90.60507>