Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Feb 2006 22:04:41 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Rohit Jalan <rohitj@purpe.com>
Cc:        hackers@freebsd.org
Subject:   Re: UMA zone allocator memory fragmentation questions
Message-ID:  <20060228215910.S2248@fledge.watson.org>
In-Reply-To: <20060227104341.GA6671@desk01.n2.purpe.com>
References:  <20060227104341.GA6671@desk01.n2.purpe.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Feb 2006, Rohit Jalan wrote:

> Is there an upper limit on the amount of fragmentation / wastage that can 
> occur in a UMA zone?
>
> Is there a method to know the total number of pages used by a UMA zone at 
> some instance of time?

Hey there Rohit,

UMA allocates pages retrieved from VM as "slabs".  It's behavior depends a bit 
on how large the allocated object is, as it's a question of packing objects 
into page-sized slabs for small objects, or packing objects into sets of pages 
making up a slab for larger objects.  You can programmatically access 
information on UMA using libmemstat(3), which allows you to do things like 
query the current object cache size, total lifetime allocations for the zone, 
allocation failure count, sizes of per-cpu caches, etc.  You may want to take 
a glance at the source code for vmstat -z and netstat -m for examples of it in 
use.  You'll notice, for example, that netstat -m reports on both the mbufs in 
active use, and also the memory allocated to mbufs in the percpu + zone 
caches, since that memory is also (for the time being) committed to the mbuf 
allocator.  The mbuf code is a little hard to follow because there are 
actually two zones that allocate mbufs, the mbuf zone and the packet secondary 
zone, so let me know if you have any questions.

If you want to dig down a bit more, uma_int.h includes the keg and zone 
definitions, and you can extracting information like the page maximum, the 
number of items per page or pages per item, etc.  If there's useful 
information that you need but isn't currently exposed by libmemstat, we can 
add it easily enough.  You might also be interested in some of the tools at

     http://www.watson.org/~robert/freebsd/libmemstat/

Include memtop, which is basically an activity monitor for kernel memory 
types.  As an FYI, kernel malloc is wrapped around UMA, so if you view both 
malloc and UMA stats at once, there is double-counting.

Robert N M Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060228215910.S2248>