From owner-freebsd-hackers@freebsd.org Wed Nov 25 17:57:07 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54F58A37147 for ; Wed, 25 Nov 2015 17:57:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32226122C; Wed, 25 Nov 2015 17:57:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4EE17B93B; Wed, 25 Nov 2015 12:57:06 -0500 (EST) From: John Baldwin To: Ian Lepore Cc: freebsd-hackers@freebsd.org Subject: Re: vmstat -m strangeness Date: Wed, 25 Nov 2015 09:56:41 -0800 Message-ID: <11036450.1jCBAH2oOF@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <1448422356.1297.5.camel@freebsd.org> References: <1445378386.14127.2.camel@freebsd.org> <1769220.C3nP8qXIrX@ralph.baldwin.cx> <1448422356.1297.5.camel@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Nov 2015 12:57:06 -0500 (EST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 17:57:07 -0000 On Tuesday, November 24, 2015 08:32:36 PM Ian Lepore wrote: > On Tue, 2015-11-24 at 17:10 -0800, John Baldwin wrote: > > On Tuesday, October 20, 2015 03:59:46 PM Ian Lepore wrote: > > > root@wand:~ # vmstat -m | egrep "busdma|bounce|devbuf|Type" > > > Type InUse MemUse HighUse Requests Size(s) > > > devbuf 125 10K - 166 16,32,64,256,512,1024 > > > busdma 922 116K - 922 128 > > > bounce 385 775K - 385 32,128 > > > > > > How do 385 allocations of 32 or 128 bytes add up to 775K? The > > > answer... 768K of individual pages each allocated via > > > contigmalloc() do > > > n't show up in that output. Why is that, and is it something that > > > should be fixed? > > > > Hmm. The output is "correct", it's just that these small allocations > > have > > relatively high overhead (PAGE_SIZE - 32 for a 32 byte allocation, > > etc.). > > > > Not sure if there's a way to explain (in vmstat output) why the > > overhead for > > certain malloc buckets is so high. Perhaps the vmstat(8) manpage > > could be > > expanded to explain what MemUse is and list the contigmalloc() case > > explicitly > > as one possible reason for high overhead? > > > > I think I wasn't very clear. There are 385 small allocations (mostly > 32 byte) which are using 7 pages. The other 768 pages were allocated > by calling contigmalloc() 768 times asking for one page. The > strangeness is that those pages aren't reflected in that output. > There's no '4096' category in sizes. > > To put it another way, contigmalloc() is accounting for the memory it > allocates in a way that makes it show up in MemUse but not in Size(s), > which makes for confusing output. No big deal really, just something I > noticed. Oh, that is indeed odd. I'm not sure how one could address that cleanly since contigmalloc takes arbitrary sizes. (E.g. it wouldn't be really correct to count a contigmalloc() of 8 pages as 8 1-page allocations though that is one way we could do this (by treating any contigmalloc() as N 1-page allocations).) -- John Baldwin