From: Andrey Konovalov <andreyknvl@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Question about freeing of empty per-CPU partial slabs in SLUB
Date: Tue, 10 Sep 2024 18:38:42 +0200 [thread overview]
Message-ID: <CA+fCnZfFZCCq6ZQuVHoKY2tRJ3z1p0ftPW360-s=1JWd5Rv3JQ@mail.gmail.com> (raw)
Hi Vlastimil (and other SLUB maintainers),
I have a question about freeing of empty per-CPU partial slabs in the
SLUB allocator.
The "Linux SLUB Allocator Internals and Debugging" article [1] states:
"If the partial slab becomes an empty slab after freeing up the
object, it will be left in its current list if the number of partial
slabs for the concerned node is within the limits (i.e < slab cache’s
min_partial). This applies to both slabs belonging to a per-cpu
partial slab list and slabs belonging to a per-node partial slab list.
If the number of partial slabs are outside the limit (i.e >= slab
cache’s min partial) then the newly available empty slab is freed and
is removed from the corresponding partial slab list."
The part that seems wrong to me here is the statement that this
applies to the per-CPU partial list. Based on the code in __slab_free,
it looks like it cannot reach the slab_empty label for a slab that is
on the per-CPU partial list.
(I know that an empty per-CPU partial slab can be freed when the list
overflows or via shrinking, the question is about the slab being freed
directly by __slab_free.)
Is the article wrong with regards to this case? Or did this behavior
change recently (I failed found any traces of this)?
Other than this statement, the article seems to be correct about all
other small details that I looked into, so I'm not sure whether my
understanding of the code is wrong of the article is.
I hope you could clarify this.
Thank you!
[1] https://blogs.oracle.com/linux/post/linux-slub-allocator-internals-and-debugging-1
next reply other threads:[~2024-09-10 16:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 16:38 Andrey Konovalov [this message]
2024-09-12 8:34 ` Vlastimil Babka
2024-09-13 13:27 ` Andrey Konovalov
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='CA+fCnZfFZCCq6ZQuVHoKY2tRJ3z1p0ftPW360-s=1JWd5Rv3JQ@mail.gmail.com' \
--to=andreyknvl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox