Thread (21 messages) 21 messages, 5 authors, 2018-07-17

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

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!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help