vmstat -m strangeness

[Ian Lepore]

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.

-- Ian