Re: [PATCH RFC 12/12] mm/slab: stop allocating objcg pointers when unnecessary

Harry Yoo <[email protected]>
Newsgroups org.kernel.vger.cgroups,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 7/17/26 12:32 AM, Suren Baghdasaryan wrote:
> On Thu, Jul 16, 2026 at 8:08 AM Vlastimil Babka (SUSE)
> <[email protected]> wrote:
>>
>> On 7/16/26 06:46, Suren Baghdasaryan wrote:
>>> Maybe now we should rename static_obj_ext_size() to
>>> static_obj_ext_max_size() as it reflects the max possible size of
>>> slabobj_ext?
>>
>> Hm with _max_size() it doesn't have to be called static_ anymore?
> 
> Yeah, static_ is an implementation detail anyway.
> 
>> But maybe we can get rid of it completely.
>>
>> The only caller is calculate_sizes():
> 
> I was thinking the same but either way sounds fine to me. Keeping
> obj_ext_max_size() would be a bit more self-documenting I think.
> 
>>
>> #if defined(CONFIG_SLAB_OBJ_EXT) && defined(CONFIG_64BIT)
>>         if (slab_args_unmergeable(args, s->flags) &&
>>                         (aligned_size - size >= static_obj_ext_size()))
>>                 s->flags |= SLAB_OBJ_EXT_IN_OBJ;
>> #endif
>>
>> We don't have slab pointer to pass to static_obj_ext_max_size().
>> But we should be able to figure it out from the cache via
>> cache_needs_objcg().
>>
>> So we'd need cache_obj_ext_size()?

That sounds good?

slab_obj_ext_size() takes slab parameter only to optimize access
but the obj_exts size is already per-cache property.

>> The static max size here works, but may prevent SLAB_OBJ_EXT_IN_OBJ
>> needlessly if padding can only fit codetag_ref and not objcg, but
>> we don't need objcg.
>> Which is probably only theoretical at this point as kmalloc_normal
>> caches (that have no objcg) have no padding, at least without
>> slab_debug. But still.
> 
> Maybe keep it simple as is for now and then we can optimize it further?

But cache_obj_ext_size() isn't adding much complexity?

Not sure why we would need something that represents
"maximum size of obj_exts across the system" anyway...

-- 
Cheers,
Harry / Hyeonggon
OpenPGP_signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCalnbjwAKCRCGXBN6rc5S
1kz3AP0c8Fcvhsk6QCY076Qq9xU7Ajbm6fPXywxZG2uE2iNtXwD8Da200DO4Q7ge
R8RmBS3245J6QFXDzPNcrjCpLU1oPg0=
=loeC
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.