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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello David,

On Wed, 15 Jul 2020 00:00:03 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> wrote:

> On Tue, 14 Jul 2020, David Rientjes 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.


Thanks,
SeongJae Park



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux