From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Chengming Zhou <zhouchengming@bytedance.com>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
David Rientjes <rientjes@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mm/slub: directly load freelist from cpu partial slab in the likely case
Date: Wed, 17 Jan 2024 14:41:13 -0800 (PST) [thread overview]
Message-ID: <76641777-1918-2b29-b6aa-bda9b5467aa3@gentwo.org> (raw)
In-Reply-To: <20240117-slab-misc-v1-1-fd1c49ccbe70@bytedance.com>
On Wed, 17 Jan 2024, Chengming Zhou wrote:
> The likely case is that we get a usable slab from the cpu partial list,
> we can directly load freelist from it and return back, instead of going
> the other way that need more work, like reenable interrupt and recheck.
Ok I see that it could be useful to avoid the unlock_irq/lock_irq sequence
in the partial cpu handling.
> But we need to remove the "VM_BUG_ON(!new.frozen)" in get_freelist()
> for reusing it, since cpu partial slab is not frozen. It seems
> acceptable since it's only for debug purpose.
This is test for verification that the newly acquired slab is actually in
frozen status. If that test is no longer necessary then this is a bug that
may need to be fixed independently. Maybe this test is now required to be
different depending on where the partial slab originated from? Check only
necessary when taken from the per node partials?
> There is some small performance improvement too, which shows by:
> perf bench sched messaging -g 5 -t -l 100000
>
> mm-stable slub-optimize
> Total time 7.473 7.209
Hmm... Good avoiding the lock/relock sequence helps.
next prev parent reply other threads:[~2024-01-17 22:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 11:45 [PATCH 0/3] mm/slub: some minor optimization and cleanup Chengming Zhou
2024-01-17 11:45 ` [PATCH 1/3] mm/slub: directly load freelist from cpu partial slab in the likely case Chengming Zhou
2024-01-17 22:41 ` Christoph Lameter (Ampere) [this message]
2024-01-18 11:37 ` Chengming Zhou
2024-01-18 22:14 ` Christoph Lameter (Ampere)
2024-01-19 3:53 ` Chengming Zhou
2024-01-22 17:13 ` Vlastimil Babka
2024-01-23 2:51 ` Chengming Zhou
2024-01-23 7:42 ` Chengming Zhou
2024-01-23 8:24 ` Vlastimil Babka
2024-01-23 9:17 ` Chengming Zhou
2024-01-17 11:45 ` [PATCH 2/3] mm/slub: remove full list manipulation for non-debug slab Chengming Zhou
2024-01-17 22:44 ` Christoph Lameter (Ampere)
2024-01-23 8:45 ` Vlastimil Babka
2024-01-17 11:46 ` [PATCH 3/3] mm/slub: remove unused parameter in next_freelist_entry() Chengming Zhou
2024-01-23 8:47 ` Vlastimil Babka
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=76641777-1918-2b29-b6aa-bda9b5467aa3@gentwo.org \
--to=cl@gentwo.org \
--cc=42.hyeyoo@gmail.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=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
--cc=zhouchengming@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