David Collier-Brown wrote:
> Actually Sean's asking for a clue about the *virtual* memory behavior.
The pagelist and the cachelist contain page objects, which have an
associated physical page. He's actually talking about physical memory,
since you'll never have more pages on any of these lists than you will
have physical pages in the system.
On Tue, Jun 30, 2009 at 04:31:11PM -0700, Richard Elling wrote:
> Sean Liu wrote:
>> Before Solaris 8, vmstat freemem only shows freelist, so after UFS
>> cache took all of the free memory, freelist will eventually shrink to
>> minfree. And that's the behavior you talked about. However with
>> Solaris 8, vmstat freemem shows freelist + cachelist, where
>> cachelist is the UFS cache which is considered FREE because it gives
>> back memory to applications.
>>
>
> The same is true of the ARC, except that the mechanism for
> returning memory to the free pool does not depend on the
> page scanner.
The mechanism that the ARC uses for returning memory to the system is
different than the way pages are pulled off the cachelist. Unmapped
non-ZFS pages that are still backed with file content get free'd to the
cache list where they can easily be reallocated by a call to
page_create_va().
The ARC uses kmem. The kmem allocator takes a larger chunk of memory,
called a slab, and carves that up into multiple objects. Individual
objects allocated in the ARC have an underlying kmem slab that
represents a larger chunk of contiguous kernel virtual memory. If you
want the pages back from the kva, that entire slab has to be free'd and
destroyed before the pages can be reallocated elsewhere.
This means that if you've allocated a slab that contains 6 objects and
one of them is in use, your free count will be 5 objects. Except that
you can't actually destroy these objects and re-use their pages until
the 6th object is free'd. At that point, you can claim all 6 and
destroy the slab. Until then, what's listed as free isn't really free.
>> At this moment, ZFS does not have anything like cachelist to report
>> how much memory to give back so we are back to reactive mode again.
>>
>
> this would be, to the first order, instantaneously, from kstat -n arcstats
> c - c_min
>
> This equation does not belong in the vmstat free list column.
I agree. In fact it probably doesn't make sense to have the cachelist
be in the free column, since that's not really free either. It makes
more sense to break this down into memory that's free, memory that's
cached, and memory that's in-use. That way folks are able to see all
three, and can treat the cached memory as free if so desired.
Linux has a tool that displays information in a similar format. It
might be useful as a point of reference:
http://wiki.linuxquestions.org/wiki/Free_%28command%29
-j
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
