All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>,
	"Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Hao Li <hao.li@linux.dev>, Shakeel Butt <shakeel.butt@linux.dev>,
	Alexander Potapenko <glider@google.com>,
	Marco Elver <elver@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@gentwo.org>,
	David Rientjes <rientjes@google.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org
Subject: Re: [PATCH RFC 12/12] mm/slab: stop allocating objcg pointers when unnecessary
Date: Fri, 17 Jul 2026 16:36:47 +0900	[thread overview]
Message-ID: <5d96283c-46fb-43e4-ac83-fb1b860fd6df@kernel.org> (raw)
In-Reply-To: <CAJuCfpFicmMa54V5qVY7BYQuNih9u+-bQ+x51VDza7zWPK_mOg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1939 bytes --]



On 7/17/26 12:32 AM, Suren Baghdasaryan wrote:
> On Thu, Jul 16, 2026 at 8:08 AM Vlastimil Babka (SUSE)
> <vbabka@kernel.org> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2026-07-17  7:36 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 10:10 [PATCH RFC 00/12] mm/slab, alloc_tag: reduce obj_ext memory waste Vlastimil Babka (SUSE)
2026-07-15 10:10 ` [PATCH RFC 01/12] mm/slab: skip kfence objects in allocation profiling Vlastimil Babka (SUSE)
2026-07-15 16:02   ` Suren Baghdasaryan
2026-07-16  9:11     ` Vlastimil Babka (SUSE)
2026-07-16 15:24       ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 02/12] mm/slab: remove objs_per_slab() Vlastimil Babka (SUSE)
2026-07-15 16:13   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 03/12] mm: move struct slabobj_ext to mm/slab.h Vlastimil Babka (SUSE)
2026-07-16  0:56   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 04/12] mm/slab: make slab_obj_ext() determine object index Vlastimil Babka (SUSE)
2026-07-16  1:02   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 05/12] mm/slab: abstract slabobj_ext.objcg access Vlastimil Babka (SUSE)
2026-07-16  1:27   ` Suren Baghdasaryan
2026-07-16 13:58     ` Vlastimil Babka (SUSE)
2026-07-16 15:27       ` Suren Baghdasaryan
2026-07-17 10:00   ` Vlastimil Babka (SUSE)
2026-07-15 10:10 ` [PATCH RFC 06/12] mm/slab: abstract slabobj_ext.ref access Vlastimil Babka (SUSE)
2026-07-16  1:28   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 07/12] mm/slab: replace slab.stride with obj_exts_in_object Vlastimil Babka (SUSE)
2026-07-16  1:44   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 08/12] mm/slab: change struct slabobj_ext to a union Vlastimil Babka (SUSE)
2026-07-16  4:11   ` Suren Baghdasaryan
2026-07-16 14:43     ` Vlastimil Babka (SUSE)
2026-07-16 15:28       ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 09/12] mm/slab: introduce slab_obj_ext_has_codetag() Vlastimil Babka (SUSE)
2026-07-16  4:25   ` Suren Baghdasaryan
2026-07-16 14:47     ` Vlastimil Babka (SUSE)
2026-07-15 10:10 ` [PATCH RFC 10/12] mm/slab: reduce slabobj_ext memory with allocation profiling disabled Vlastimil Babka (SUSE)
2026-07-16  4:30   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 11/12] mm/slab: add slab_needs_objcg() helper Vlastimil Babka (SUSE)
2026-07-16  4:36   ` Suren Baghdasaryan
2026-07-15 10:10 ` [PATCH RFC 12/12] mm/slab: stop allocating objcg pointers when unnecessary Vlastimil Babka (SUSE)
2026-07-16  4:46   ` Suren Baghdasaryan
2026-07-16 15:08     ` Vlastimil Babka (SUSE)
2026-07-16 15:32       ` Suren Baghdasaryan
2026-07-17  7:36         ` Harry Yoo [this message]
2026-07-15 15:32 ` [PATCH RFC 00/12] mm/slab, alloc_tag: reduce obj_ext memory waste Suren Baghdasaryan
2026-07-16  3:28   ` Harry Yoo
2026-07-16  4:55     ` Suren Baghdasaryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d96283c-46fb-43e4-ac83-fb1b860fd6df@kernel.org \
    --to=harry@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@gentwo.org \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=hao.li@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.