From: Harry Yoo <harry.yoo@oracle.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Suren Baghdasaryan <surenb@google.com>,
Alexei Starovoitov <ast@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, kasan-dev@googlegroups.com
Subject: Re: [PATCH 1/5] slab: make __slab_free() more clear
Date: Fri, 7 Nov 2025 10:48:34 +0900 [thread overview]
Message-ID: <aQ1P8mHnv6_FE7Fh@harry> (raw)
In-Reply-To: <a1922c8a-6cd1-4d79-8a7a-7462a1e791f5@suse.cz>
On Thu, Nov 06, 2025 at 09:43:24AM +0100, Vlastimil Babka wrote:
> On 11/6/25 09:26, Harry Yoo wrote:
> > On Wed, Nov 05, 2025 at 10:05:29AM +0100, Vlastimil Babka wrote:
> >> The function is tricky and many of its tests are hard to understand. Try
> >> to improve that by using more descriptively named variables and added
> >> comments.
> >>
> >> - rename 'prior' to 'old_head' to match the head and tail parameters
> >> - introduce a 'bool was_full' to make it more obvious what we are
> >> testing instead of the !prior and prior tests
> >
> > Yeah I recall these were cryptic when I was analyzing slab few years
> > ago :)
> >
> >> - add or improve comments in various places to explain what we're doing
> >>
> >> Also replace kmem_cache_has_cpu_partial() tests with
> >> IS_ENABLED(CONFIG_SLUB_CPU_PARTIAL) which are compile-time constants.
> >>
> >> We can do that because the kmem_cache_debug(s) case is handled upfront
> >> via free_to_partial_list().
> >
> > This makes sense. By the way, should we also check IS_ENABLED(CONFIG_SLUB_TINY)
> > in kmem_cache_has_cpu_partial()?
>
> If you really mean testing CONFIG_SLUB_TINY then it's not necessary because
> CONFIG_SLUB_CPU_PARTIAL depends on !TINY.
I really meant this and yeah I missed that!
> If you mean using IS_ENABLED(CONFIG_SLUB_CPU_PARTIAL) instead of the #ifdef,
> that could be possible, just out of scope here. And hopefully will be gone
> fully, so no point in polishing at this point. Unlike __slab_free() which stays.
Agreed.
> >> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> >> ---
> >
> > The code is much cleaner!
> >
> > Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2025-11-07 1:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 9:05 [PATCH 0/5] slab: preparatory cleanups before adding sheaves to all caches Vlastimil Babka
2025-11-05 9:05 ` [PATCH 1/5] slab: make __slab_free() more clear Vlastimil Babka
2025-11-06 8:26 ` Harry Yoo
2025-11-06 8:43 ` Vlastimil Babka
2025-11-07 1:48 ` Harry Yoo [this message]
2025-11-05 9:05 ` [PATCH 2/5] slab: move kfence_alloc() out of internal bulk alloc Vlastimil Babka
2025-11-06 2:39 ` Alexei Starovoitov
2025-11-06 7:23 ` Vlastimil Babka
2025-11-10 8:06 ` Harry Yoo
2025-11-05 9:05 ` [PATCH 3/5] slab: handle pfmemalloc slabs properly with sheaves Vlastimil Babka
2025-11-10 9:53 ` Harry Yoo
2025-11-05 9:05 ` [PATCH 4/5] slub: remove CONFIG_SLUB_TINY specific code paths Vlastimil Babka
2025-11-13 1:52 ` Harry Yoo
2025-11-05 9:05 ` [PATCH 5/5] slab: prevent recursive kmalloc() in alloc_empty_sheaf() Vlastimil Babka
2025-11-13 4:55 ` Harry Yoo
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=aQ1P8mHnv6_FE7Fh@harry \
--to=harry.yoo@oracle.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cl@gentwo.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/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.