From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 21 06:38:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C0421065696; Tue, 21 Sep 2010 06:38:55 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 818658FC17; Tue, 21 Sep 2010 06:38:54 +0000 (UTC) Received: by gxk8 with SMTP id 8so1932020gxk.13 for ; Mon, 20 Sep 2010 23:38:54 -0700 (PDT) Received: by 10.101.136.30 with SMTP id o30mr10502522ann.224.1285051133708; Mon, 20 Sep 2010 23:38:53 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id d4sm13839209and.39.2010.09.20.23.38.50 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Sep 2010 23:38:52 -0700 (PDT) Date: Mon, 20 Sep 2010 20:39:58 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andriy Gapon In-Reply-To: <4C984E90.60507@freebsd.org> Message-ID: References: <4C93236B.4050906@freebsd.org> <4C935F56.4030903@freebsd.org> <4C95C804.1010701@freebsd.org> <4C95CCDA.7010007@freebsd.org> <4C984E90.60507@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 21 Sep 2010 10:38:19 +0000 Cc: Andre Oppermann , Jeff Roberson , Robert Watson , freebsd-hackers@freebsd.org Subject: Re: zfs + uma X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 06:38:55 -0000 On Tue, 21 Sep 2010, Andriy Gapon wrote: > 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). I'm afraid there is not enough context here for me to know what 'the same mechanism' is or what solaris does. Can you elaborate? I prefer not to take the weight of specific examples too heavily when considering the allocator as it must handle many cases and many types of systems. I believe there are cases where you want large allocations to be handled by per-cpu caches, regardless of whether ZFS is one such case. If ZFS does not need them, then it should simply allocate directly from the VM. However, I don't want to introduce some maximum constraint unless it can be shown that adequate behavior is not generated from some more adaptable algorithm. Thanks, Jeff > > -- > Andriy Gapon >