From: Christoph Lameter <cl@gentwo.de>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: Queueing is outside of SLUB nowdays
Date: Mon, 4 Oct 2021 16:56:36 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2110041648220.294708@gentwo.de> (raw)
In-Reply-To: <20211001003908.GA2657@linux.asia-northeast3-a.c.our-ratio-313919.internal>
On Fri, 1 Oct 2021, Hyeonggon Yoo wrote:
> Looking at other layers, they implemented queuing layer outside of SLUB.
> See commit 795bb1c00dd ("net: bulk free infrastructure for NAPI context,
> use napi_consume_skb") for example. They made skb cache because SLUB is
> not suitable for intensive alloc/free.
>
> And because the queue is outside of slab, it can go lockless
> depending on it's context. (But it's not easy to do so in slab because
> slab is general purpose allocator.)
The queuing within in SLUB/SLAB is lockless.
> So current approach on place where slab's performance is critical
> is implementing queuing layer on top of slab.
If you have to use object specific characteristics to optimize then yes
you can optimize further. However, the slab allocators implement each
their own form of queuing that is generic.
> Then new question arising:
> - Is that proper way to solve fundamental problem?
There is a problem?
> - why not use SLAB if they need queuing?
SLAB is LIFO queuing whereas SLUB uses spatial considerations and queues
within a page before going outside. Slab requires disabling interrupts,
SLUB is optimized to rely on per cpu atomics and there are numerous other
differences.
> - how does this approach work on SLAB?
SLAB has a lockless layer that is only requiring disabling interrupts. It
provides a generic queuing layer as well.
See my talk on Slab allocators awhile back.
https://www.youtube.com/watch?v=h0VMLXavx30
next prev parent reply other threads:[~2021-10-04 14:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-27 9:03 [QUESTION] is SLAB considered legacy and deprecated? Hyeonggon Yoo
2021-09-27 17:03 ` Vlastimil Babka
2021-09-28 11:12 ` Hyeonggon Yoo
2021-09-29 10:50 ` Hyeonggon Yoo
2021-10-01 14:07 ` Vlastimil Babka
2021-10-03 5:59 ` Hyeonggon Yoo
2021-10-04 1:25 ` David Rientjes
2021-10-04 6:01 ` Hyeonggon Yoo
2021-10-04 11:39 ` Vlastimil Babka
2021-10-05 13:31 ` Hyeonggon Yoo
2021-10-04 11:34 ` Vlastimil Babka
2021-10-04 14:22 ` Hyeonggon Yoo
2021-10-01 0:39 ` Queueing is outside of SLUB nowdays Hyeonggon Yoo
2021-10-04 14:56 ` Christoph Lameter [this message]
2021-10-05 8:19 ` Vlastimil Babka
2021-10-05 14:16 ` Hyeonggon 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=alpine.DEB.2.22.394.2110041648220.294708@gentwo.de \
--to=cl@gentwo.de \
--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=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;
as well as URLs for NNTP newsgroup(s).