Received-SPF: pass (google.com: domain of linux-kernel+bounces-163099-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240427003733.3898961-1-shakeel.butt@linux.dev>
 <20240427003733.3898961-4-shakeel.butt@linux.dev> <CABdmKX0Mo74f-AjY46cyPwd2qSpwmj4CLvYVCEywq_PEsVmd9w@mail.gmail.com>
 <j4dsapl5hu2enzoq5c7y3z2bqksk6fpygkk5t45ok7d5v3gdt2@5ygpjaj2hiva>
In-Reply-To: <j4dsapl5hu2enzoq5c7y3z2bqksk6fpygkk5t45ok7d5v3gdt2@5ygpjaj2hiva>
From: "T.J. Mercier" <tjmercier@google.com>
Date: Mon, 29 Apr 2024 15:23:28 -0700
Message-ID: <CABdmKX0OQM65dRK29XCAUrnJt2yv=p7i00Cpc9V9FGuOEfuZ_g@mail.gmail.com>
Subject: Re: [PATCH v2 3/7] memcg: reduce memory for the lruvec and memcg stats
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, 
	Michal Hocko <mhocko@kernel.org>, Roman Gushchin <roman.gushchin@linux.dev>, 
	Muchun Song <muchun.song@linux.dev>, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 29, 2024 at 1:13=E2=80=AFPM Shakeel Butt <shakeel.butt@linux.de=
v> wrote:
>
> On Mon, Apr 29, 2024 at 10:35:38AM -0700, T.J. Mercier wrote:
> > On Fri, Apr 26, 2024 at 5:37=E2=80=AFPM Shakeel Butt <shakeel.butt@linu=
x.dev> wrote:
> > >
> [...]
> > > +
> > > +static const unsigned int memcg_stat_items[] =3D {
> > > +       MEMCG_SWAP,
> > > +       MEMCG_SOCK,
> > > +       MEMCG_PERCPU_B,
> > > +       MEMCG_VMALLOC,
> > > +       MEMCG_KMEM,
> > > +       MEMCG_ZSWAP_B,
> > > +       MEMCG_ZSWAPPED,
> > > +};
> >
> > Unsigned for these? All the values are positive now, but I don't think
> > we'll get a build warning if a negative one ever got added, just a
> > crash or corruption. BUG_ON in init_memcg_stats if a
> > memcg_stat_items[i] < 0?
>
> We are depending on NR_VM_NODE_STAT_ITEMS to tell the number of elements
> for vmstats. So, I think there is an implicit assumption that there are
> no negative enums in enum node_stat_item. So, if we want to verify those
> assumptions then we should be adding such warnings/build-bugs in vmstat
> first.

Ok fair. I guess this if we get C23:

enum node_stat_item : unsigned {