vmstat -m strangeness

[John Baldwin]

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 at 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