From owner-svn-src-head@FreeBSD.ORG Wed Jun 19 00:26:29 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 900FCD4B; Wed, 19 Jun 2013 00:26:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA021E4A; Wed, 19 Jun 2013 00:26:29 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (unknown [63.118.227.34]) by elvis.mu.org (Postfix) with ESMTPSA id 105411A3C19; Tue, 18 Jun 2013 17:26:27 -0700 (PDT) Message-ID: <51C0FAB3.7060409@mu.org> Date: Tue, 18 Jun 2013 20:26:27 -0400 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jeff Roberson Subject: Re: svn commit: r251894 - in head: lib/libmemstat sys/vm References: <201306180450.r5I4oKoY091256@svn.freebsd.org> <51C01964.1000006@freebsd.org> <20130618083733.GQ1400@FreeBSD.org> <51C04C77.7010907@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, Andre Oppermann , svn-src-all@freebsd.org, Gleb Smirnoff , svn-src-head@freebsd.org, Jeff Roberson X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 00:26:29 -0000 On 6/18/13 5:21 PM, Jeff Roberson wrote: > On Tue, 18 Jun 2013, Alfred Perlstein wrote: > >> On 6/18/13 4:37 AM, Gleb Smirnoff wrote: >>> On Tue, Jun 18, 2013 at 10:25:08AM +0200, Andre Oppermann wrote: >>> A> There used to be a problem with per CPU caches accumulating large >>> amounts >>> A> of items without freeing back to the global (or socket) pool. >>> A> >>> A> Do these updates to UMA change this situation and/or do you have >>> further >>> A> improvements coming up? >>> >>> This is especially a problem with ZFS, which utilizes UMA extensively. >>> >>> IMHO, we need a flag for uma_zcreate() that would disable per CPU >>> caches, so >>> that certain zones (ZFS at least) would have them off. >>> >>> It might be a good idea to force this flag on every zone that has >>> allocation >= >>> then the page size. >>> >> What about people running with 256GB+ ram? Do they also want the per >> cpu caches off? > > If you look at the new system there is a static threshold for the > initial item size required for different sized per-cpu buckets. What > might make sense is to tune this size based on available memory. For > what it's worth I looked at solaris settings and they cache roughly 4x > as much on a per-cpu basis. > > The new system should tend to cache less of large and infrequent > allocations vs the old system. I can't say yet whether it is still a > problem. > > I have an implementation of vmem to replace using vm_maps for > kmem_map, buffer_map, etc. which may resolve the zfs allocation > problems. I hope to get this in over the next few weeks. > That looks really exciting Jeff. Thank you. I'm hoping we can give back some testing numbers when it goes in. -Alfred