From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: [RFC] Some questions and an idea on SLUB/SLAB
Date: Sat, 9 Oct 2021 00:19:03 +0000 [thread overview]
Message-ID: <20211009001903.GA3285@kvm.asia-northeast3-a.c.our-ratio-313919.internal> (raw)
Questions:
- Is there a reason that SLUB does not implement cache coloring?
it will help utilizing hardware cache. Especially in block layer,
they are literally *squeezing* its performance now.
- In SLAB, do we really need to flush queues every few seconds?
(per cpu queue and shared queue). Flushing alien caches makes
sense, but flushing queues seems reducing it's fastpath.
But yeah, we need to reclaim memory. can we just defer this?
Idea:
- I don't like SLAB's per-node cache coloring, because L1 cache
isn't shared between cpus. For now, cpus in same node are sharing
its colour_next - but we can do better.
what about splitting some per-cpu variables into kmem_cache_cpu
like SLUB? I think cpu_cache, colour (and colour_next),
alloc{hit,miss}, and free{hit,miss} can be per-cpu variables.
next reply other threads:[~2021-10-09 0:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 0:19 Hyeonggon Yoo [this message]
2021-10-09 0:33 ` Matthew Wilcox
2021-10-09 0:40 ` Hyeonggon Yoo
2021-10-09 2:02 ` Hyeonggon Yoo
2021-10-09 11:45 ` Almost no difference Hyeonggon Yoo
2021-10-11 7:13 ` [RFC] Some questions and an idea on SLUB/SLAB Christoph Lameter
2021-10-13 3:44 ` 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=20211009001903.GA3285@kvm.asia-northeast3-a.c.our-ratio-313919.internal \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--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