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

[Slawa Olhovchenkov]

On Wed, Sep 04, 2019 at 09:27:00AM +0300, Andriy Gapon wrote:

> On 04/09/2019 01:01, Mark Johnston wrote:
> > Some of the vm_lowmem eventhandlers probably shouldn't be called each
> > time the page daemon scans the inactive queue (every 0.1s under memory
> > pressure).  ufsdirhash_lowmem and mb_reclaim in particular don't seem
> > like they need to be invoked very frequently.  We could easily define
> > multiple eventhandlers to differentiate between these cases, though.
> 
> My proposal is to run uma_reclaim(UMA_RECLAIM_TRIM) before invoking vm_lowmem.
> If that reclaims "enough" memory, then do not call vm_lowmem at all.
> 
> Oh, and I have a related question.
> Say, a zone has X items in use and Y items in cache.
> After running vm_lowmem the composition changes to X - C and Y + C respectively.
> Then we run uma_reclaim(UMA_RECLAIM_TRIM).
> Question: is that guaranteed to free at least C items?
> I am thinking about a possibility that the zone's workset size is estimated to
> be at least X (and maybe even more than X + Y).  In that case UMA_RECLAIM_TRIM
> won't free those C items, they will stay in the cache.  So, it seems like
> releasing them was in vain, at least for the immediate reclaim.

My goal is uma_reclaim(UMA_RECLAIM_TRIM) reclaim from zone cache up to zone cache working set.
Idealy in stable run uma_reclaim(UMA_RECLAIM_TRIM) do nothing and all
allocation/free from zone go from/to zone cache. As result
uma_reclaim(UMA_RECLAIM_TRIM) work only for rebalance memory consume at
working profile change.