Received-SPF: pass (google.com: domain of linux-kernel+bounces-109497-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Wed, 20 Mar 2024 19:45:16 -0400
From: Johannes Weiner <hannes@cmpxchg.org>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Muchun Song <muchun.song@linux.dev>, linux-mm@kvack.org,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: remove CONFIG_MEMCG_KMEM
Message-ID: <20240320234516.GJ294822@cmpxchg.org>
References: <20240320202745.740843-1-hannes@cmpxchg.org>
 <Zftk3tzC2btb3Ine@P9FQF9L96D>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zftk3tzC2btb3Ine@P9FQF9L96D>

On Wed, Mar 20, 2024 at 03:36:14PM -0700, Roman Gushchin wrote:
> On Wed, Mar 20, 2024 at 04:27:45PM -0400, Johannes Weiner wrote:
> > CONFIG_MEMCG_KMEM used to be a user-visible option for whether slab
> > tracking is enabled. It has been default-enabled and equivalent to
> > CONFIG_MEMCG for almost a decade. We've only grown more kernel memory
> > accounting sites since, and there is no imaginable cgroup usecase
> > going forward that wants to track user pages but not the multitude of
> > user-drivable kernel allocations.
> 
> I totally support it. I believe one of the reasons for it to exist
> was SLOB, which hasn't been supporting the slab memory accounting.
> No such reasons anymore.

Yeah. The funny thing is, if you had slob selected, it would also
disable all the other kernel memory accounting covered by that option
that had nothing to do with the slab allocator.

This patch certainly got a much more simpler without slob around.

> Acked-by: Roman Gushchin <roman.gushchin@linux.dev>

Thanks :)