Re: [PATCH 07/12] mm, slab: ignore SLAB_RECLAIM_ACCOUNT with CONFIG_SLUB_TINY

From: Vlastimil Babka <vbabka@suse.cz>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>,
	patches@lists.linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/12] mm, slab: ignore SLAB_RECLAIM_ACCOUNT with CONFIG_SLUB_TINY
Date: Thu, 24 Nov 2022 10:09:03 +0100	[thread overview]
Message-ID: <23028c8a-7e53-6993-e076-6df8a6939313@suse.cz> (raw)
In-Reply-To: <Y37GxICuaRbwK+tj@P9FQF9L96D.corp.robot.car>

On 11/24/22 02:20, Roman Gushchin wrote:
> On Mon, Nov 21, 2022 at 06:11:57PM +0100, Vlastimil Babka wrote:
>> SLAB_RECLAIM_ACCOUNT caches allocate their slab pages with
>> __GFP_RECLAIMABLE and can help against fragmentation by grouping pages
>> by mobility, but on tiny systems mobility grouping is likely disabled
>> anyway and ignoring SLAB_RECLAIM_ACCOUNT might instead lead to merging
>> of caches that are made incompatible just by the flag.
>> 
>> Thus with CONFIG_SLUB_TINY, make SLAB_RECLAIM_ACCOUNT ineffective.
> 
> Hm, do you see disabling all kernel memory accounting functionality
> with COFNIG_SLUB_TINY? I'd say yes. But in this case need to be consistent
> and disable it alltogether.

SLAB_RECLAIM_ACCOUNT is kinda misnomer these days, as the only thing it does
is to add __GFP_RECLAIMABLE to cache's gfp flags for the page allocator's
mobility grouping. I guess the "ACCOUNT" part comes from being counted
towards SReclaimable (vs SUnreclaim) in /proc/meminfo.

So currently SLUB_TINY has no effect on MEMCG_KMEM (which you probably
meant). Using those two together has little sense and had I stumbled while
making this series upon a code that would become complicated, I would have
made SLUB_TINY disable MEMCG_KMEM, but that didn't happen so I left as is
for now.

> Thanks!