From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Gushchin Subject: Re: [PATCH v2 5/7] mm: rename and change semantics of nr_indirectly_reclaimable_bytes Date: Tue, 17 Jul 2018 11:54:54 -0700 Message-ID: <20180717185451.GA18762@castle.DHCP.thefacebook.com> References: <20180618091808.4419-6-vbabka@suse.cz> <201806201923.mC5ZpigB%fengguang.wu@intel.com> <38c6a6e1-c5e0-fd7d-4baf-1f0f09be5094@suse.cz> <20180629211201.GA14897@castle.DHCP.thefacebook.com> <20180702165223.GA17295@castle.DHCP.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Vlastimil Babka Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Johannes Weiner , linux-api@vger.kernel.org, Christoph Lameter , David Rientjes , Mel Gorman , Matthew Wilcox , Vijayanand Jitta , Laura Abbott , Sumit Semwal List-Id: linux-api@vger.kernel.org On Tue, Jul 17, 2018 at 10:44:07AM +0200, Vlastimil Babka wrote: > On 07/02/2018 06:52 PM, Roman Gushchin wrote: > > On Sat, Jun 30, 2018 at 12:09:27PM +0200, Vlastimil Babka wrote: > >> 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? > > > > 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. > > BTW, seems you seem interested, could you provide some more formal > review as well? Others too. We don't need to cover all use cases > immediately, when the patchset is apparently stalled due to lack of > review. Thanks! Sure! The patchset looks sane at a first glance, but I need some time to dig deeper. Is v2 the final version? Thanks!