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

[Harry Yoo]

On 7/17/26 12:32 AM, Suren Baghdasaryan wrote:
> On Thu, Jul 16, 2026 at 8:08 AM Vlastimil Babka (SUSE)
> <vbabka@xxxxxxxxxx> 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

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature