linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Christoph Lameter <cl@gentwo.org>,
	Matthew Wilcox <willy@infradead.org>,
	Christoph Lameter <cl@gentwo.de>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Do we really need SLOB nowdays?
Date: Wed, 15 Dec 2021 06:29:04 +0000	[thread overview]
Message-ID: <20211215062904.GA1150813@odroid> (raw)
In-Reply-To: <cbfaeb40-13c7-15b6-177d-07b3f3c4a0a9@suse.cz>

On Tue, Dec 14, 2021 at 06:24:58PM +0100, Vlastimil Babka wrote:
> On 12/10/21 13:06, Christoph Lameter wrote:
> > On Fri, 10 Dec 2021, Hyeonggon Yoo wrote:
> > 
> >> > > (But I still have doubt if we can run linux on machines like that.)
> >> >
> >> > I sent you a series of articles about making Linux run in 1MB.
> >>
> >> After some time playing with the size of kernel,
> >> I was able to run linux in 6.6MiB of RAM. and the SLOB used
> >> around 300KiB of memory.
> > 
> > What is the minimal size you need for SLUB?
>  

I don't know why Christoph's mail is not in my mailbox. maybe I deleted it
by mistake or I'm not cc-ed.

Anyway, I tried to measure this again with SLUB and SLOB.

SLUB uses few hundreds of bytes than SLOB.

There isn't much difference in 'Memory required to boot'.
(interestingly SLUB requires less)

'Memory required to boot' is measured by reducing memory
until it says 'System is deadlocked on memory'. I don't know
exact reason why they differ.

Note that the configuration is based on tinyconfig and
I added initramfs support + tty layer (+ uart driver) + procfs support,
+ ELF binary support + etc.

there isn't even block layer, but it's good starting point to see
what happens in small system.

SLOB:

	Memory required to boot: 6950K

	/proc/meminfo:
		MemTotal:           4820 kB
		MemFree:            1172 kB
		MemAvailable:        800 kB
		Buffers:               0 kB
		Cached:             2528 kB
		SwapCached:            0 kB
		Active:                4 kB
		Inactive:            100 kB
		Active(anon):          4 kB
		Inactive(anon):      100 kB
		Active(file):          0 kB
		Inactive(file):        0 kB
		Unevictable:        2528 kB
		Mlocked:               0 kB
		SwapTotal:             0 kB
		SwapFree:              0 kB
		Dirty:                 0 kB
		Writeback:             0 kB
		AnonPages:           120 kB
		Mapped:              848 kB
		Shmem:                 0 kB
		KReclaimable:          0 kB
		Slab:                368 kB
		SReclaimable:          0 kB
		SUnreclaim:          368 kB
		KernelStack:         128 kB
		PageTables:           28 kB
		NFS_Unstable:          0 kB
		Bounce:                0 kB
		WritebackTmp:          0 kB
		CommitLimit:        2408 kB
		Committed_AS:        524 kB
		VmallocTotal:    1032192 kB
		VmallocUsed:          16 kB
		VmallocChunk:          0 kB
		Percpu:               32 kB

SLUB:
	Memory required to boot: 6800K

	/proc/meminfo:
		MemTotal:           4660 kB
		MemFree:             836 kB
		MemAvailable:        568 kB
		Buffers:               0 kB
		Cached:             2528 kB
		SwapCached:            0 kB
		Active:                4 kB
		Inactive:            100 kB
		Active(anon):          4 kB
		Inactive(anon):      100 kB
		Active(file):          0 kB
		Inactive(file):        0 kB
		Unevictable:        2528 kB
		Mlocked:               0 kB
		SwapTotal:             0 kB
		SwapFree:              0 kB
		Dirty:                 0 kB
		Writeback:             0 kB
		AnonPages:           120 kB
		Mapped:              848 kB
		Shmem:                 0 kB
		KReclaimable:        188 kB
		Slab:                552 kB
		SReclaimable:        188 kB
		SUnreclaim:          364 kB
		KernelStack:         128 kB
		PageTables:           28 kB
		NFS_Unstable:          0 kB
		Bounce:                0 kB
		WritebackTmp:          0 kB
		CommitLimit:        2328 kB
		Committed_AS:        524 kB
		VmallocTotal:    1032192 kB
		VmallocUsed:          16 kB
		VmallocChunk:          0 kB
		Percpu:               32 kB

SLUB with slab merging:

	Memory required to boot: 6800K
	/proc/meminfo:
		MemTotal:           4660 kB
		MemFree:             840 kB
		MemAvailable:        572 kB
		Buffers:               0 kB
		Cached:             2528 kB
		SwapCached:            0 kB
		Active:                4 kB
		Inactive:            100 kB
		Active(anon):          4 kB
		Inactive(anon):      100 kB
		Active(file):          0 kB
		Inactive(file):        0 kB
		Unevictable:        2528 kB
		Mlocked:               0 kB
		SwapTotal:             0 kB
		SwapFree:              0 kB
		Dirty:                 0 kB
		Writeback:             0 kB
		AnonPages:           120 kB
		Mapped:              848 kB
		Shmem:                 0 kB
		KReclaimable:        188 kB
		Slab:                536 kB
		SReclaimable:        188 kB
		SUnreclaim:          348 kB
		KernelStack:         128 kB
		PageTables:           28 kB
		NFS_Unstable:          0 kB
		Bounce:                0 kB
		WritebackTmp:          0 kB
		CommitLimit:        2328 kB
		Committed_AS:        524 kB
		VmallocTotal:    1032192 kB
		VmallocUsed:          16 kB
		VmallocChunk:          0 kB
		Percpu:               32 kB



If you're interested in reproducing this,
some links below will help:

https://hyeyoo.com/148 (written in korean but the commands and pictures will help)
http://events17.linuxfoundation.org/sites/events/files/slides/tiny.pdf
http://events17.linuxfoundation.org/sites/events/files/slides/opdenacker-embedded-linux-size-reduction-techniques_0.pdf
https://lukaszgemborowski.github.io/articles/minimalistic-linux-system-on-qemu-arm.html
https://weeraman.com/building-a-tiny-linux-kernel-8c07579ae79d

the target board is ARM Versatile Platform Board (based on ARMv5).
And I ran this on qemu.

Thanks,
Hyeonggon.

> Good question. Meanwhile I tried to compare Slab: in /proc/meminfo on a virtme run:
> virtme-run --mods=auto --kdir /home/vbabka/wrk/linux/ --memory 2G,slots=2,maxmem=4G --qemu-opts --smp 4
> 
> Got ~30800kB with SLOB, 34500kB with SLUB without DEBUG and PERCPU_PARTIAL.
> Then did a quick and dirty patch (below) to never load c->slab in
> ___slab_alloc() and got to 32200kB. Fiddling with
> slub_min_order/slub_max_order didn't actually help, probably due to causing
> more internal fragmentation.
> 
> So that's relatively close, but on a really small system the difference can
> be possibly more prominent. Also my test doesn't account for text/data or
> percpu usage differences.
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 68aa112e469b..fd9c853971d1 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3054,6 +3054,8 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
>  		 */
>  		goto return_single;
>  
> +	goto return_single;
> +
>  retry_load_slab:
>  
>  	local_lock_irqsave(&s->cpu_slab->lock, flags);
> 
> 

  reply	other threads:[~2021-12-15  6:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-17  4:28 [RFC] More deterministic SLOB for real time embedded systems Hyeonggon Yoo
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
     [not found]       ` <CAB=+i9Tor-tmZuB8YjATT_rv68nnF2W_TvMvyGp55AGaSyKynw@mail.gmail.com>
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
2021-12-10 11:08               ` Hyeonggon Yoo
2021-12-10 12:06                 ` Christoph Lameter
2021-12-14 17:24                   ` Vlastimil Babka
2021-12-15  6:29                     ` Hyeonggon Yoo [this message]
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=20211215062904.GA1150813@odroid \
    --to=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.de \
    --cc=cl@gentwo.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 \
    --cc=willy@infradead.org \
    /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).