On Wed, 9 Jan 2008, Vadim Goncharov wrote:

quoted text
>>> Yes, I've known it, but didn't known what column names exactly mean. 
>>> Requests/Failures, I guess, is a pure statistics, Size is one element 
>>> size, but why USED + FREE != LIMIT (on whose where limit is non-zero) ?
>> 
>> Possibly we should rename the "FREE" column to "CACHE" -- the free count is 
>> the number of items in the UMA cache.  These may be hung in buckets off the 
>> per-CPU cache, or be spare buckets in the zone.  Either way, the memory has 
>> to be reclaimed before it can be used for other purposes, and generally for 
>> complex objects, it can be allocated much more quickly than going back to 
>> VM for more memory.  LIMIT is an administrative limit that may be 
>> configured on the zone, and is configured for some but not all zones.
>
> And every unlimited zone after growing on demand can cause 
> kmem_map/kmem_size panics, or some will low-memeory panics with message 
> about another map?

Well, there are also limits not imposed using the UMA limit mechanism, so just 
because it appears unbounded in vmstat -z doesn't mean there's no limit. 
There's no UMA zone limit on processes, but there's a separately imposed 
maxproc limit--and as a result, filedesc, which is typically one per process, 
is also bounded to approximately maxproc.  Likewise, many other data 
structures effectively scale with the number of processes, the size of 
physical memory, the size of the address space, maxusers, etc.

There are relatively few things that actually have no limit associated with 
them one way or another, precisely because if there's no limit it can lead the 
kernel to become starved of resources.  Where there isn't a limit, ideally 
privilege is required to allocate (i.e., malloc-backed swap requires root 
privilege to configure).  Sometimes the limits are much more complex than a 
single global limit, such as resources controlled using resource limits, which 
can be per-process, per-uid, etc.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"