From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f199.google.com (mail-wr0-f199.google.com [209.85.128.199]) by kanga.kvack.org (Postfix) with ESMTP id F08166B0003 for ; Mon, 30 Apr 2018 11:32:20 -0400 (EDT) Received: by mail-wr0-f199.google.com with SMTP id x7-v6so4392833wrn.13 for ; Mon, 30 Apr 2018 08:32:20 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 19-v6si691003edz.48.2018.04.30.08.32.19 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 30 Apr 2018 08:32:19 -0700 (PDT) Subject: Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat References: <20180425191422.9159-1-guro@fb.com> <20180426200331.GZ17484@dhcp22.suse.cz> <99208563-1171-b7e7-a0d7-b47b6c5e2307@suse.cz> From: Vlastimil Babka Message-ID: Date: Mon, 30 Apr 2018 17:30:17 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Michal Hocko , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, kernel-team@fb.com, Matthew Wilcox , Andrew Morton , Alexander Viro , Johannes Weiner On 04/27/2018 08:41 PM, David Rientjes wrote: > On Fri, 27 Apr 2018, Vlastimil Babka wrote: > >> It was in the original thread, see e.g. >> <08524819-14ef-81d0-fa90-d7af13c6b9d5@suse.cz> >> >> However it will take some time to get that in mainline, and meanwhile >> the current implementation does prevent a DOS. So I doubt it can be >> fully reverted - as a compromise I just didn't want the counter to >> become ABI. TBH though, other people at LSF/MM didn't seem concerned >> that /proc/vmstat is an ABI that we can't change (i.e. counters have >> been presumably removed in the past already). >> > > What prevents this from being a simple atomic_t that gets added to in > __d_alloc(), subtracted from in __d_free_external_name(), and read in > si_mem_available() and __vm_enough_memory()? The counter is already in mainline, so I think it's easier to simply just stop printing it now than trying to replace its implementation with one that can cause cache ping pongs.