Message-ID: <22e28cb5-4834-4a21-8ebb-e4e53259014c@suse.cz>
Date: Thu, 29 Aug 2024 10:42:59 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Yosry Ahmed <yosryahmed@...gle.com>, Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>,
 Roman Gushchin <roman.gushchin@...ux.dev>,
 Muchun Song <muchun.song@...ux.dev>, David Rientjes <rientjes@...gle.com>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>, Eric Dumazet <edumazet@...gle.com>,
 "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Meta kernel team <kernel-team@...a.com>,
 cgroups@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2] memcg: add charging of already allocated slab objects

On 8/29/24 02:49, Yosry Ahmed wrote:
> On Wed, Aug 28, 2024 at 5:20 PM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>>
>> On Wed, Aug 28, 2024 at 04:25:30PM GMT, Yosry Ahmed wrote:
>> > On Tue, Aug 27, 2024 at 4:52 PM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>> > >
>> [...]
>> > > +
>> > > +       /* Ignore KMALLOC_NORMAL cache to avoid circular dependency. */
>> > > +       if ((s->flags & KMALLOC_TYPE) == SLAB_KMALLOC)
>> > > +               return true;
>> >
>> > Taking a step back here, why do we need this? Which circular
>> > dependency are we avoiding here?
>>
>> commit 494c1dfe855ec1f70f89552fce5eadf4a1717552
>> Author: Waiman Long <longman@...hat.com>
>> Date:   Mon Jun 28 19:37:38 2021 -0700
>>
>>     mm: memcg/slab: create a new set of kmalloc-cg-<n> caches
>>
>>     There are currently two problems in the way the objcg pointer array
>>     (memcg_data) in the page structure is being allocated and freed.
>>
>>     On its allocation, it is possible that the allocated objcg pointer
>>     array comes from the same slab that requires memory accounting. If this
>>     happens, the slab will never become empty again as there is at least
>>     one object left (the obj_cgroup array) in the slab.
>>
>>     When it is freed, the objcg pointer array object may be the last one
>>     in its slab and hence causes kfree() to be called again. With the
>>     right workload, the slab cache may be set up in a way that allows the
>>     recursive kfree() calling loop to nest deep enough to cause a kernel
>>     stack overflow and panic the system.
>>     ...
> 
> Thanks for the reference, this makes sense.

Another reason is memory savings, if we have a small subset of objects in
KMALLOC_NORMAL caches accounted, there might be e.g. one vector per a slab
just to account on object while the rest is unaccounted. Separating between
kmalloc and kmalloc-cg caches keeps the former with no vectors and the
latter with fully used vectors.

> Wouldn't it be easier to special case the specific slab cache used for
> the objcg vector or use a dedicated cache for it instead of using
> kmalloc caches to begin with?

The problem is the vector isn't a fixed size, it depends on how many objects
a particular slab (not even a particular cache) has.

> Anyway, I am fine with any approach you and/or the slab maintainers
> prefer, as long as we make things clear. If you keep the following
> approach as-is, please expand the comment or refer to the commit you
> just referenced.
> 
> Personally, I prefer either explicitly special casing the slab cache
> used for the objcgs vector, explicitly tagging KMALLOC_NORMAL
> allocations, or having a dedicated documented helper that finds the
> slab cache kmalloc type (if any) or checks if it is a KMALLOC_NORMAL
> cache.

A helper to check is_kmalloc_normal() would be better than defining
KMALLOC_TYPE and using it directly, yes. We don't need to handle any other
types now until anyone needs those.

Powered by blists - more mailing lists