svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm

[Andriy Gapon]

On 04/09/2019 01:01, Mark Johnston wrote:
> Slawa and I talked about this in the past.  His complaint is that a
> large cache can take a significant amount of time to trim, and it
> manifests as a spike of CPU usage and contention on the zone lock.  In
> particular, keg_drain() iterates over the list of free slabs with the
> keg lock held, and if the many items were freed to the keg while
> trimming/draining, the list can be quite long.  This can have effects
> outside the zone, for example if we are reclaiming items from zones used
> by other UMA zones, like the bucket or slab zones.

My concern is different, though.
I feel that having oversized caches for long periods of time produces a skewed
picture of memory usage.  Particularly, some ZFS caches are sometimes extremely
oversized.  I don't care much about details of consequences of such oversized
caches.  I just think that that is not right on a more general level.

> Reclaiming cached items when there is no demand for free pages seems
> wrong to me.

It certainly was wrong before.
Now that we have a capability to trim a cache size to a workset size it doesn't
feel as wrong to me.

> We historically had similar problems with the page daemon,
> which last year was changed to perform smaller reclamations at a greater
> frequency.  I suspect a better approach for UMA would be to similarly
> increase reclaim frequency and reduce the number of items freed in one
> go.



-- 
Andriy Gapon