Re: Re: [patch] mm, memcg: provide a stat to describe reclaimable memory

[David Rientjes <rientjes@google.com>]

On Wed, 15 Jul 2020, SeongJae Park wrote:

> > An alternative to this would also be to change from an "available" metric 
> > to an "anon_reclaimable" metric since both the deferred split queues and 
> > lazy freeable memory would pertain to anon.  This would no longer attempt 
> > to mimic MemAvailable and leave any such calculation to userspace
> > (anon_reclaimable + (file + slab_reclaimable) / 2).
> > 
> > With this route, care would need to be taken to clearly indicate that 
> > anon_reclaimable is not necessarily a subset of the "anon" metric since 
> > reclaimable memory from compound pages on deferred split queues is not 
> > mapped, so it doesn't show up in NR_ANON_MAPPED.
> > 
> > I'm indifferent to either approach and would be happy to switch to 
> > anon_reclaimable if others agree and doesn't foresee any extensibility 
> > issues.
> 
> Agreed, I was also once confused about the 'MemAvailable'.  The 'reclaimable'
> might be better to understand.
> 

Hi SeongJae,

I'm leaning in that direction now too, actually, because I reasoned that 
determining the precise amount of anon that can be reclaimed would require 
subtracting (file + slab_reclaimable) / 2, which is awkward :)

So I'll send a follow-up patch to add only an anon_reclaimable field which 
is good enough for our purposes unless others would like to have more 
discussion.

Thanks!