From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 11:27:46 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 7C5BF1065670; Sat, 18 Sep 2010 11:27:46 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB628FC17; Sat, 18 Sep 2010 11:27:45 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA05660; Sat, 18 Sep 2010 14:27:44 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Owva3-000Cwf-Oi; Sat, 18 Sep 2010 14:27:43 +0300 Message-ID: <4C94A22F.1070608@freebsd.org> Date: Sat, 18 Sep 2010 14:27:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Robert Watson References: <4C93236B.4050906@freebsd.org> <4C935F56.4030903@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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: Sat, 18 Sep 2010 11:27:46 -0000 on 18/09/2010 14:23 Robert Watson said the following: > I've been keeping a vague eye out for this over the last few years, and haven't > spotted many problems in production machines I've inspected. You can use the > umastat tool in the tools tree to look at the distribution of memory over > buckets (etc) in UMA manually. It would be nice if it had some automated > statistics on fragmentation however. Short-lived fragmentation is likely, and > isn't an issue, so what you want is a tool that monitors over time and reports > on longer-lived fragmentation. > > The main fragmentation issue we've had in the past has been due to mbuf+cluster > caching, which prevented mbufs from being freed usefully in some cases. Jeff's > ongoing work on variable-sized mbufs would entirely eliminate that problem... Robert, just in case, this thread is not about fragmentation, it's about per-cpu buckets, number of items in them and size of the items. -- Andriy Gapon