From: Christopher Lameter <cl@linux.com>
To: Muchun Song <songmuchun@bytedance.com>
Cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] mm/slub: Fix slabs_node return value
Date: Wed, 17 Jun 2020 16:19:34 +0000 (UTC) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2006171616190.1574@www.lameter.com> (raw)
In-Reply-To: <20200614123923.99189-1-songmuchun@bytedance.com>
On Sun, 14 Jun 2020, Muchun Song wrote:
> The slabs_node() always return zero when CONFIG_SLUB_DEBUG is disabled.
> But some codes determine whether slab is empty by checking the return
> value of slabs_node(). As you know, the result is not correct. we move
> the nr_slabs of kmem_cache_node out of the CONFIG_SLUB_DEBUG. So we can
> get the corrent value returned by the slabs_node().
Not that all distribution kernels have CONFIG_SLUB_DEBUG enabled. This
does not enable runtime debugging but only compiles the debug code in that
can then be enabled at runtime.
Users of !CONFIG_SLUB_DEBUG do not want to have the debug code included
because they have extreme requirements on memory use.
This patch increases use of memory by enabling fields that were excluded
under !CONFIG_SLUB_DEBUG before!
There is nothing wrong with slab_node's return value if one wants to
sacrifice debugging and consistency checks for a small code build.
prev parent reply other threads:[~2020-06-17 16:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-14 12:39 Muchun Song
2020-06-14 12:39 ` [PATCH 1/3] mm/slub: Fix slabs_node return value when CONFIG_SLUB_DEBUG disabled Muchun Song
2020-06-15 6:11 ` Joonsoo Kim
2020-06-15 6:26 ` [External] " Muchun Song
2020-06-15 16:46 ` Vlastimil Babka
2020-06-14 12:39 ` [PATCH 2/3] mm/slub: Use node_nr_slabs() instead of slabs_node() Muchun Song
2020-06-15 6:15 ` Joonsoo Kim
2020-06-15 6:20 ` [External] " Muchun Song
2020-06-14 12:39 ` [PATCH 3/3] mm/slub: Fix release all resources used by a slab cache Muchun Song
2020-06-15 6:23 ` Joonsoo Kim
2020-06-15 6:41 ` [External] " Muchun Song
2020-06-15 7:25 ` Joonsoo Kim
2020-06-15 7:50 ` Muchun Song
2020-06-17 16:19 ` Christopher Lameter [this message]
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=alpine.DEB.2.22.394.2006171616190.1574@www.lameter.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=songmuchun@bytedance.com \
/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