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!
