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>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>
Subject: [RFC] More deterministic SLOB for real time embedded systems
Date: Sun, 17 Oct 2021 04:28:52 +0000 [thread overview]
Message-ID: <20211017042852.GA3050@kvm.asia-northeast3-a.c.our-ratio-313919.internal> (raw)
I've been reading SLUB/SLOB code for a while. SLUB recently became
real time compatible by reducing its locking area.
for now, SLUB is the only slab allocator for PREEMPT_RT because
it works better than SLAB on RT and SLOB uses non-deterministic method,
sequential fit.
But memory usage of SLUB is too high for systems with low memory.
So In my local repository I made SLOB to use segregated free list
method, which is more more deterministic, to provide bounded latency.
This can be done by managing list of partial pages globally
for every power of two sizes (8, 16, 32, ..., PAGE_SIZE) per NUMA nodes.
minimal allocation size is size of pointers to keep pointer of next free object
like SLUB.
By making size of objects in same page to have same size, there's no
need to iterate free blocks in a page. (Also iterating pages isn't needed)
Some cleanups and more tests (especially with NUMA/RT configs) needed,
but want to hear your opinion about the idea. Did not test on RT yet.
Below is result of benchmarks and memory usage. (on !RT)
with 13% increase in memory usage, it's nine times faster and
bounded fragmentation, and importantly provides predictable execution time.
current SLOB:
memory usage:
Slab: 7936 kB
hackbench:
Time: 263.900
Performance counter stats for 'hackbench -g 4 -l 10000':
527649.37 msec cpu-clock # 1.999 CPUs utilized
12451963 context-switches # 23.599 K/sec
251231 cpu-migrations # 476.132 /sec
4112 page-faults # 7.793 /sec
342196899596 cycles # 0.649 GHz
228439896295 instructions # 0.67 insn per cycle
3228211614 branch-misses
65667138978 cache-references # 124.452 M/sec
7406902357 cache-misses # 11.279 % of all cache refs
263.956975106 seconds time elapsed
5.213166000 seconds user
521.716737000 seconds sys
SLOB with segregated free list:
memory usage:
Slab: 8976 kB
hackbench:
Time: 28.896
Performance counter stats for 'hackbench -g 4 -l 10000':
57669.66 msec cpu-clock # 1.995 CPUs utilized
902343 context-switches # 15.647 K/sec
10569 cpu-migrations # 183.268 /sec
4116 page-faults # 71.372 /sec
72101524728 cycles # 1.250 GHz
68780577270 instructions # 0.95 insn per cycle
230133481 branch-misses
23610741192 cache-references # 409.414 M/sec
896060729 cache-misses # 3.795 % of all cache refs
28.909188264 seconds time elapsed
1.521686000 seconds user
56.105718000 seconds sys
next reply other threads:[~2021-10-17 4:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-17 4:28 Hyeonggon Yoo [this message]
2021-10-17 13:36 ` segregated list + slab merging is much better than original SLOB Hyeonggon Yoo
2021-10-17 13:57 ` Do we really need SLOB nowdays? Hyeonggon Yoo
2021-10-17 14:39 ` Matthew Wilcox
2021-10-18 9:45 ` Hyeonggon Yoo
2021-10-25 8:17 ` Christoph Lameter
2021-10-28 10:04 ` Hyeonggon Yoo
2021-10-28 12:08 ` Matthew Wilcox
2021-10-30 6:12 ` Hyeonggon Yoo
[not found] ` <20211210110835.GA632811@odroid>
2021-12-10 12:06 ` Christoph Lameter
2021-12-14 17:24 ` Vlastimil Babka
[not found] ` <20211215062904.GA1150813@odroid>
2021-12-15 10:10 ` Vlastimil Babka
2021-12-15 15:23 ` Christoph Lameter
2022-02-18 10:13 ` Hyeonggon Yoo
2022-02-18 10:37 ` Hyeonggon Yoo
2022-02-18 16:10 ` David Laight
2022-02-19 11:59 ` Hyeonggon Yoo
2021-10-25 8:15 ` Christoph Lameter
2021-10-25 8:14 ` [RFC] More deterministic SLOB for real time embedded systems Christoph Lameter
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=20211017042852.GA3050@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