Received-SPF: pass (google.com: domain of linux-kernel+bounces-12854-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 28 Dec 2023 12:43:30 -0800 (PST)
From: David Rientjes <rientjes@google.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
cc: Andrew Morton <akpm@linux-foundation.org>, 
    Linus Torvalds <torvalds@linux-foundation.org>, 
    Greg Kroah-Hartman <gregkh@linuxfoundation.org>, rafael@kernel.org, 
    surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
    souravpanda@google.com
Subject: Re: Sysfs one-value-per-file (was Re: [PATCH] vmstat: don't auto
 expand the sysfs files)
In-Reply-To: <CA+CK2bAARPNHwZB9tkd6miKr8GWrZ_L6h1oiUM0qWu6pJqh3Wg@mail.gmail.com>
Message-ID: <c2b73ac2-c271-d11c-6d06-3e0ab74a29a6@google.com>
References: <20231211154644.4103495-1-pasha.tatashin@soleen.com> <3d415ab4-e8c7-7e72-0379-952370612bdd@google.com> <CA+CK2bA2vZp3e+HHfB-sdLsPUYghMxvKcWURktDtNjwPL79Csw@mail.gmail.com> <b1049bfa-68c4-e237-30a9-1514a378c7f1@google.com>
 <CA+CK2bBxbvO-osm5XKk4VkaXYgfZXkDAtfayaYJ-vXo=QFqGPA@mail.gmail.com> <13e5fbd4-d84d-faba-47f1-d0024d2c572d@google.com> <20231227104244.824b0977ae6d4bb6b37f6f79@linux-foundation.org> <CA+CK2bAARPNHwZB9tkd6miKr8GWrZ_L6h1oiUM0qWu6pJqh3Wg@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

On Thu, 28 Dec 2023, Pasha Tatashin wrote:

> > > But for existing files and conventions, I think we should settle it as
> > > "keep doing what you've been doing for 13+ years" and don't force this
> > > argument every time a kernel developer wants to just add one more stat.
> >
> > Absolutely.  Let's do what makes most sense.  For new things, one value
> > per file.  For stats which logically group with other existing stats,
> > do whatever the existing other stats are currently doing.
> 
> The intent of "[PATCH] vmstat: don't auto expand the sysfs files" is
> to do exactly this: keep the current fields in
> /sys/devices/system/node/node*/vmstat as-is, but prevent future fields
> added to node_stat, numa_stat, zone_stat from showing in vmstat.
> 

This is the opposite of what Andrew and I wrote above.  There should be no 
need to start preventing future stats from being grouped together in 
vmstat if it logically makes sense.

NAK.