From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751300AbdCQVVQ (ORCPT <rfc822;w@1wt.eu>);
        Fri, 17 Mar 2017 17:21:16 -0400
Received: from mail-pf0-f177.google.com ([209.85.192.177]:34672 "EHLO
        mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751198AbdCQVVO (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 17 Mar 2017 17:21:14 -0400
Date: Fri, 17 Mar 2017 14:21:12 -0700 (PDT)
From: David Rientjes <rientjes@google.com>
X-X-Sender: rientjes@chino.kir.corp.google.com
To: Michal Hocko <mhocko@kernel.org>
cc: Andrew Morton <akpm@linux-foundation.org>,
        Anshuman Khandual <khandual@linux.vnet.ibm.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Mel Gorman <mgorman@techsingularity.net>,
        Johannes Weiner <hannes@cmpxchg.org>, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org
Subject: Re: [patch v2] mm, vmstat: print non-populated zones in zoneinfo
In-Reply-To: <20170317085737.GE26298@dhcp22.suse.cz>
Message-ID: <alpine.DEB.2.10.1703171416070.81333@chino.kir.corp.google.com>
References: <alpine.DEB.2.10.1703021525500.5229@chino.kir.corp.google.com> <4acf16c5-c64b-b4f8-9a41-1926eed23fe1@linux.vnet.ibm.com> <alpine.DEB.2.10.1703031445340.92298@chino.kir.corp.google.com> <alpine.DEB.2.10.1703031451310.98023@chino.kir.corp.google.com>
 <20170308144159.GD11034@dhcp22.suse.cz> <20170317085737.GE26298@dhcp22.suse.cz>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 17 Mar 2017, Michal Hocko wrote:

> > Does it really make sense to print any counters of that zone though?
> > Your follow up patch just suggests that we don't want some but what
> > about others?
> > 

Managed and present pages needs to be emitted for userspace parsing of 
memory hotplug, I chose not to suppress the five or six other members 
since the risk of breaking existing parsers far outweighs any savings from 
not emitting these lines.  There is already plenty of opportunities to 
clean /proc/zoneinfo up as described by Andrew that may be possible but 
care needs to taken to ensure we don't break existing readers.