Re: zfs pool behavior - is it ever freed?

[mlelstv%serpens.de@localhost (Michael van Elst)]

gdt%lexort.com@localhost (Greg Troxel) writes:

>mlelstv%serpens.de@localhost (Michael van Elst) writes:

>> tnn%NetBSD.org@localhost (Tobias Nygren) writes:
>>
>>>There exists ZFS code which hooks into UVM to drain memory -- but part
>>>of it is ifdef __i386 for some reason. See arc_kmem_reap_now().
>>
>> That's an extra for 32bit systems (later code replaced __i386 with
>> the proper macro) where kernel address space is much smaller.

>Sure, but I don't see why it shouldn't always be hooked up.

It might have negative effects, as its used to reduce non-zfs-related
pools. The zfs-related-pools are freed in any case.

I think our problem is that the vcache doesn't get enough pressure.
For FreeBSD you will find the dnlc_reduce_cache() function in arc.c
that (in a separate thread) reduces metadata held by the kernel so that
buffers actually get unreferenced and can be freed afterwards.

We do have the vdrain_thread() that tries to keep cached vnodes
(and associated metadata) below the 'desiredvnodes' value. That
value however doesn't change under memory pressure. You can manually
change the value (as kern.maxvnodes) to get an immediate effect
(for e.g. UFS).

For ZFS however that apparently isn't enough. I can shrink the
vcache, but the ZFS buffers seem to be unaffected.