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

[Mark Johnston]

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?

No.  The estimation cannot distinguish between items that were freed as
a result of a lowmem request vs. those that were freed as a regular
operation.  As a result it considers the extra C items as part of the
cache's working size.

> 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.

This is true.  Of course, the items may eventually become reclaimable as
the estimate decays.