[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef2dea13-0102-c4bc-a28f-c1b2408f0753@suse.cz>
Date: Sat, 30 Jun 2018 12:09:27 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Roman Gushchin <guro@...com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...nel.org>,
Johannes Weiner <hannes@...xchg.org>,
linux-api@...r.kernel.org, Christoph Lameter <cl@...ux.com>,
David Rientjes <rientjes@...gle.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Matthew Wilcox <willy@...radead.org>,
Vijayanand Jitta <vjitta@...eaurora.org>,
Laura Abbott <labbott@...hat.com>,
Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH v2 5/7] mm: rename and change semantics of
nr_indirectly_reclaimable_bytes
On 06/29/2018 11:12 PM, Roman Gushchin wrote:
>>
>> 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?
Powered by blists - more mailing lists