From owner-svn-src-all@FreeBSD.ORG Tue Jun 18 08:37:36 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C0C5667; Tue, 18 Jun 2013 08:37:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id BEE091708; Tue, 18 Jun 2013 08:37:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r5I8bXUf024896; Tue, 18 Jun 2013 12:37:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r5I8bX18024895; Tue, 18 Jun 2013 12:37:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 18 Jun 2013 12:37:33 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: svn commit: r251894 - in head: lib/libmemstat sys/vm Message-ID: <20130618083733.GQ1400@FreeBSD.org> References: <201306180450.r5I4oKoY091256@svn.freebsd.org> <51C01964.1000006@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <51C01964.1000006@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, Jeff Roberson , src-committers@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:37:36 -0000 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. -- Totus tuus, Glebius.