On Wed, 9 Jan 2008, Vadim Goncharov wrote: >>> 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 CambridgeReceived on Tue Jan 08 2008 - 18:22:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:25 UTC