Re: [PATCH v2 5/7] mm: rename and change semantics of nr_indirectly_reclaimable_bytes
From: Roman Gushchin <hidden>
Date: 2018-07-02 16:53:38
Also in:
linux-mm, lkml
From: Roman Gushchin <hidden>
Date: 2018-07-02 16:53:38
Also in:
linux-mm, lkml
On Sat, Jun 30, 2018 at 12:09:27PM +0200, Vlastimil Babka wrote:
On 06/29/2018 11:12 PM, Roman Gushchin wrote:quoted
quoted
The vmstat counter NR_INDIRECTLY_RECLAIMABLE_BYTES was introduced by commit eb59254608bc ("mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES") with the goal of accounting objects that can be reclaimed, but cannot be allocated via a SLAB_RECLAIM_ACCOUNT cache. This is now possible via kmalloc() with __GFP_RECLAIMABLE flag, and the dcache external names user is converted. The counter is however still useful for accounting direct page allocations (i.e. not slab) with a shrinker, such as the ION page pool. So keep it, and:Btw, it looks like I've another example of usefulness of this counter: dynamic per-cpu data.Hmm, but are those reclaimable? Most likely not in general? Do you have examples that are?
If these per-cpu data is something like per-cpu refcounters, which are using to manage reclaimable objects (e.g. cgroup css objects). Of course, they are not always reclaimable, but in certain states. Thanks!