When will ZFS become stable?

[Vadim Goncharov]

08.01.08 @ 05:39 Robert Watson wrote:

> On Tue, 8 Jan 2008, Vadim Goncharov wrote:
>
>>> To make life slightly more complicated, small malloc allocations are  
>>> actually implemented using uma -- there are a small number of small  
>>> object size zones reserved for this purpose, and malloc just rounds up  
>>> to the next such bucket size and allocations from that bucket.  For  
>>> larger sizes, malloc goes through uma, but pretty much directly to VM  
>>> which makes pages available directly.  So when you look at "vmstat -z"  
>>> output, be aware that some of the information presented there (zones  
>>> named things like "128", "256", etc) are actually the pools from which  
>>> malloc allocations come, so there's double-counting.
>>
>> 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?

> I'll let someone with a bit more VM experience follow up with more  
> information about how the various maps and submaps relate to each other.

That would be good, as I still don'tany idea about exact meaning of those  
sysctls :-) Thans for explanations, though. How is our Mr. VM nowadays?..

>>> (which can be swapped out under heavy memory load), pipe buffers, and  
>>> general cached data for the buffer cache / file system, which will be  
>>> paged out or discarded when memory pressure goes up.
>>
>> Umm. I think there is no point in swapping disk cache which can be  
>> discarded, so the most actual part of kernel memory which is swappable  
>> are anonymous pipe(2) buffers?
>
> Yes, that's what I meant.  There are some other types of pageable kernel  
> memory, such as memory used for swap-backed md devices.

Hmm, I do remember messages about malloc-backed md devices panics (with  
workaround advices to switch to swap-backed md), yes...

-- 
WBR, Vadim Goncharov