From owner-freebsd-fs@FreeBSD.ORG Wed Oct 5 01:01:41 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A7751065672 for ; Wed, 5 Oct 2011 01:01:41 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 349B78FC12 for ; Wed, 5 Oct 2011 01:01:40 +0000 (UTC) Received: from ip-136.ish.com.au ([203.29.62.136]:57753 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1RBFra-0001m7-1B; Wed, 05 Oct 2011 12:01:34 +1100 X-CTCH-RefID: str=0001.0A150204.4E8BAC6E.0093:SCFSTAT15613948, ss=1, re=-4.000, fgs=0 Message-ID: <4E8BAC6A.3060301@ish.com.au> Date: Wed, 05 Oct 2011 12:01:30 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0) Gecko/20110916 Thunderbird/7.0 MIME-Version: 1.0 To: Artem Belevich References: <4E8A8740.100@ish.com.au> <4E8ACE1E.4060608@ish.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: vm.kmem_size_scale recommendation for ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:01:41 -0000 On 5/10/11 11:31 AM, Artem Belevich wrote: > On Tue, Oct 4, 2011 at 2:13 AM, Aristedes Maniatis wrote: >> But back to the original question. Pawel recommends in his 1 year old blog >> entry that kmem should be 150% of actual RAM (I don't really understand why, >> but he is the expert). Andriy committed scale=1 earlier this year which is >> more like 97% of actual RAM. Which is correct? >> >> I understand how ARC works, but I don't understand why kmem is tunable in >> ordinary operation or why one value should be preferred. > > Think of packing randomly sized round pebbles (randomly sized ARC data > chunks in this case) into square boxes (power-of-2 allocator bins or > perhaps multiples of 4K pages for larger allocations). It's obvious > that you will not be able to reach 100% utilization. kmem_size > provides address space for the allocator which will then map physical > memory there. Hence if you want to use certain amount of physical > memory in kernel, you should make sure that kmem_map is large enough > to accommodate it including the overhead. So then I assume because this kernel memory is wired to physical RAM, assigning kmem to a large number will never cause ARC to end up in swap? Is the only downside to a larger value of kmem (say double actual RAM) that there are some allocation map entries which take up space and subtract from the actual space available? Are they significant in size? If not, then setting kmem fairly high would avoid any problems of letting ARC bump into the kmem value. Thanks for this information. This is really helpful. I don't have rights to add it to the FreeBSD wiki, but I'll try and post a blog entry on my own site once I understand it all. Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A