Shouldn't this be trim, not drain? We need to free some memory but not all. Possibly we need to guarantee that trim does something even if wss is reached but otherwise this is more expensive than it needs to be.

There is also a stray * in the comment above that you could remove while you're here.

Here again, do we need to drain the whole thing or just free some memory?

I'm confused about this. Why are we reclaiming from all zones after we reclaim some vnodes? Presumably a bunch of zones related to vfs now have some free memory. This should be a TRIM at most and now that we have more regular grooming I think it could be omitted entirely.

I missed the review for the working set-size. Where is that?

Isn't mbuf cluster zone exhaustion a fairly exceptional situation? They usually indicate an mbuf leak in my experience. In that case mbuf packet allocations will likely be failing too, and even a trim will require the cluster zone lock so it's an expensive operation regardless. Will fix the comment.

Hmm, it was added somewhat recently, in r291244. I don't know that we can assume regular grooming is going be happening concurrent to this?

I agree that trimming is probably sufficient, especially in the absence of memory pressure.

D16666, just for the record, but you already commented on it.

The boot defaults for clusters are relatively low and sometimes if you have a lot of interfaces it will trip more often because so much is sitting in receive queues. At isilon the zone sizes were tuned up substantially from the defaults so the only time it happened there was with a leak.

It's not a regression to leave it this way but I would possibly appreciate a comment about it.

I find this somewhat concerning. Perhaps we can get kib to comment. Again it's not your regression to fix but this really looks like overkill to me.

If we exceeded the vnode limit, and then flushed number of vnodes back to under it, we certainly could have overuse of the related zones. I do not remember was that uma_reclaim() call added by the original bde patch, or was it added after pho tests demonstrated the need.

I do not object against less significant reclaim (TRIM in the patch terminology).

Isilon just removed the limits entirely. OneFS also has patches to allow sockbuf limits to be overridden.

I will ask Peter to test this version, which just trims the caches.

AFAIR the problems were with ZFS. UFS was relatively ok.

That makes sense given ZFS' heavy usage of UMA for large buffers. FWIW, earlier versions of this patch were tested by some ZFS users who reported seeing stalls when uma_reclaim() was called regularly by the page daemon.