All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rustam Kovhaev <rkovhaev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Alexander Shiyan <shc_work@mail.ru>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	openrisc@lists.librecores.org, linux-riscv@lists.infradead.org,
	linux-sh@vger.kernel.org
Subject: Re: Deprecating and removing SLOB
Date: Wed, 9 Nov 2022 17:50:08 +0200	[thread overview]
Message-ID: <20221109155008.GC307514@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <87187c52-ae48-130b-6479-ae1023915bc1@suse.cz>

Hi,

On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >> I believe SLOB can be removed because:
> >>
> >> - AFAIK nobody really uses it? It strives for minimal memory footprint
> >> by putting all objects together, which has its CPU performance costs
> >> (locking, lack of percpu caching, searching for free space...). I'm not
> >> aware of any "tiny linux" deployment that opts for this. For example,
> >> OpenWRT seems to use SLUB and the devices these days have e.g. 128MB
> >> RAM, not up to 16 MB anymore. I've heard anecdotes that the performance
> >> SLOB impact is too much for those who tried. Googling for
> >> "CONFIG_SLOB=y" yielded nothing useful.
> > 
> > I am all for removing SLOB.
> > 
> > There are some devices with configs where SLOB is enabled by default.
> > Perhaps, the owners/maintainers of those devices/configs should be
> > included into this thread:

[...]

> > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y

I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
better debugging features and the memory footprint difference doesn't
really matter for my use cases. Looking at history why SLOB was added
there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
when separate boards configs were merged, and SX1 board happened to have
SLOB in there. This board is nowadays only used in QEMU anyway.

There are OMAP1 boards with only 16 MB, but support for those boards
will be removed. So from OMAP1 side, I don't think there is any real
need for SLOB anymore.

A.

WARNING: multiple messages have this Message-ID (diff)
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rustam Kovhaev <rkovhaev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Alexander Shiyan <shc_work@mail.ru>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	openrisc@lists.librecores.org, linux-riscv@lists.infradead.org,
	linux-sh@vger.kernel.org
Subject: Re: Deprecating and removing SLOB
Date: Wed, 9 Nov 2022 17:50:08 +0200	[thread overview]
Message-ID: <20221109155008.GC307514@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <87187c52-ae48-130b-6479-ae1023915bc1@suse.cz>

Hi,

On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >> I believe SLOB can be removed because:
> >>
> >> - AFAIK nobody really uses it? It strives for minimal memory footprint
> >> by putting all objects together, which has its CPU performance costs
> >> (locking, lack of percpu caching, searching for free space...). I'm not
> >> aware of any "tiny linux" deployment that opts for this. For example,
> >> OpenWRT seems to use SLUB and the devices these days have e.g. 128MB
> >> RAM, not up to 16 MB anymore. I've heard anecdotes that the performance
> >> SLOB impact is too much for those who tried. Googling for
> >> "CONFIG_SLOB=y" yielded nothing useful.
> > 
> > I am all for removing SLOB.
> > 
> > There are some devices with configs where SLOB is enabled by default.
> > Perhaps, the owners/maintainers of those devices/configs should be
> > included into this thread:

[...]

> > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y

I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
better debugging features and the memory footprint difference doesn't
really matter for my use cases. Looking at history why SLOB was added
there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
when separate boards configs were merged, and SX1 board happened to have
SLOB in there. This board is nowadays only used in QEMU anyway.

There are OMAP1 boards with only 16 MB, but support for those boards
will be removed. So from OMAP1 side, I don't think there is any real
need for SLOB anymore.

A.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rustam Kovhaev <rkovhaev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Alexander Shiyan <shc_work@mail.ru>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	openrisc@lists.librecores.org, linux-riscv@lists.infradead.org,
	linux-sh@vger.kernel.org
Subject: Re: Deprecating and removing SLOB
Date: Wed, 9 Nov 2022 17:50:08 +0200	[thread overview]
Message-ID: <20221109155008.GC307514@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <87187c52-ae48-130b-6479-ae1023915bc1@suse.cz>

Hi,

On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >> I believe SLOB can be removed because:
> >>
> >> - AFAIK nobody really uses it? It strives for minimal memory footprint
> >> by putting all objects together, which has its CPU performance costs
> >> (locking, lack of percpu caching, searching for free space...). I'm not
> >> aware of any "tiny linux" deployment that opts for this. For example,
> >> OpenWRT seems to use SLUB and the devices these days have e.g. 128MB
> >> RAM, not up to 16 MB anymore. I've heard anecdotes that the performance
> >> SLOB impact is too much for those who tried. Googling for
> >> "CONFIG_SLOB=y" yielded nothing useful.
> > 
> > I am all for removing SLOB.
> > 
> > There are some devices with configs where SLOB is enabled by default.
> > Perhaps, the owners/maintainers of those devices/configs should be
> > included into this thread:

[...]

> > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y

I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
better debugging features and the memory footprint difference doesn't
really matter for my use cases. Looking at history why SLOB was added
there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
when separate boards configs were merged, and SX1 board happened to have
SLOB in there. This board is nowadays only used in QEMU anyway.

There are OMAP1 boards with only 16 MB, but support for those boards
will be removed. So from OMAP1 side, I don't think there is any real
need for SLOB anymore.

A.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Aaro Koskinen <aaro.koskinen@iki.fi>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Rich Felker <dalias@libc.org>,
	linux-sh@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Christoph Lameter <cl@linux.com>,
	linux-riscv@lists.infradead.org, Jonas Bonn <jonas@southpole.se>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Matthew Wilcox <willy@infradead.org>,
	David Rientjes <rientjes@google.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Josh Triplett <josh@joshtriplett.org>,
	openrisc@lists.librecores.org,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Alexander Shiyan <shc_work@mail.ru>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rustam Kovhaev <rkovhaev@gmail.com>,
	Pekka Enberg <penberg@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Deprecating and removing SLOB
Date: Wed, 9 Nov 2022 17:50:08 +0200	[thread overview]
Message-ID: <20221109155008.GC307514@darkstar.musicnaut.iki.fi> (raw)
In-Reply-To: <87187c52-ae48-130b-6479-ae1023915bc1@suse.cz>

Hi,

On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >> I believe SLOB can be removed because:
> >>
> >> - AFAIK nobody really uses it? It strives for minimal memory footprint
> >> by putting all objects together, which has its CPU performance costs
> >> (locking, lack of percpu caching, searching for free space...). I'm not
> >> aware of any "tiny linux" deployment that opts for this. For example,
> >> OpenWRT seems to use SLUB and the devices these days have e.g. 128MB
> >> RAM, not up to 16 MB anymore. I've heard anecdotes that the performance
> >> SLOB impact is too much for those who tried. Googling for
> >> "CONFIG_SLOB=y" yielded nothing useful.
> > 
> > I am all for removing SLOB.
> > 
> > There are some devices with configs where SLOB is enabled by default.
> > Perhaps, the owners/maintainers of those devices/configs should be
> > included into this thread:

[...]

> > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y

I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
better debugging features and the memory footprint difference doesn't
really matter for my use cases. Looking at history why SLOB was added
there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
when separate boards configs were merged, and SX1 board happened to have
SLOB in there. This board is nowadays only used in QEMU anyway.

There are OMAP1 boards with only 16 MB, but support for those boards
will be removed. So from OMAP1 side, I don't think there is any real
need for SLOB anymore.

A.

  reply	other threads:[~2022-11-09 15:50 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 15:55 Deprecating and removing SLOB Vlastimil Babka
2022-11-08 18:18 ` Christophe Leroy
2022-11-08 19:17   ` Andrew Morton
2022-11-08 18:46 ` Roman Gushchin
2022-11-08 20:13   ` Yosry Ahmed
2022-11-09  9:09     ` Vlastimil Babka
2022-11-08 21:44 ` Pasha Tatashin
2022-11-09  9:00   ` Vlastimil Babka
2022-11-09  9:00     ` Vlastimil Babka
2022-11-09  9:00     ` Vlastimil Babka
2022-11-09  9:00     ` Vlastimil Babka
2022-11-09 15:50     ` Aaro Koskinen [this message]
2022-11-09 15:50       ` Aaro Koskinen
2022-11-09 15:50       ` Aaro Koskinen
2022-11-09 15:50       ` Aaro Koskinen
2022-11-09 16:45       ` Geert Uytterhoeven
2022-11-09 16:45         ` Geert Uytterhoeven
2022-11-09 16:45         ` Geert Uytterhoeven
2022-11-09 16:45         ` Geert Uytterhoeven
2022-11-09 17:45       ` Mike Rapoport
2022-11-09 17:45         ` Mike Rapoport
2022-11-09 17:45         ` Mike Rapoport
2022-11-09 17:45         ` Mike Rapoport
2022-11-09 21:16       ` Janusz Krzysztofik
2022-11-09 21:16         ` Janusz Krzysztofik
2022-11-09 21:16         ` Janusz Krzysztofik
2022-11-09 21:16         ` Janusz Krzysztofik
2022-11-09 17:57   ` Conor.Dooley
2022-11-09 23:00     ` Damien Le Moal
2022-11-11 10:25       ` Vlastimil Babka
2022-11-12  1:40         ` Damien Le Moal
2022-11-11 10:33   ` Vlastimil Babka
2022-11-11 10:33     ` Vlastimil Babka
2022-11-11 10:33     ` Vlastimil Babka
2022-11-11 10:33     ` Vlastimil Babka
2022-11-11 12:49     ` [lkp] [+5395 bytes kernel size regression] [i386-tinyconfig] [b7c8731082] " kernel test robot
2022-11-11 17:24       ` Josh Triplett
2022-11-11 21:11         ` Vlastimil Babka
2022-11-17  8:57         ` Vlastimil Babka
2022-11-11 20:46     ` Conor Dooley
2022-11-11 20:46       ` Conor Dooley
2022-11-11 20:46       ` Conor Dooley
2022-11-11 20:46       ` Conor Dooley
2022-11-12  1:40       ` Damien Le Moal
2022-11-12  1:40         ` Damien Le Moal
2022-11-12  1:40         ` Damien Le Moal
2022-11-12  1:40         ` Damien Le Moal
2022-11-14  1:55       ` Damien Le Moal
2022-11-14  1:55         ` Damien Le Moal
2022-11-14  1:55         ` Damien Le Moal
2022-11-14  1:55         ` Damien Le Moal
2022-11-14  5:48         ` Damien Le Moal
2022-11-14  5:48           ` Damien Le Moal
2022-11-14  5:48           ` Damien Le Moal
2022-11-14  5:48           ` Damien Le Moal
2022-11-14  9:36           ` Vlastimil Babka
2022-11-14  9:36             ` Vlastimil Babka
2022-11-14  9:36             ` Vlastimil Babka
2022-11-14  9:36             ` Vlastimil Babka
2022-11-14 11:35             ` Damien Le Moal
2022-11-14 11:35               ` Damien Le Moal
2022-11-14 11:35               ` Damien Le Moal
2022-11-14 11:35               ` Damien Le Moal
2022-11-14 14:47               ` Hyeonggon Yoo
2022-11-14 14:47                 ` Hyeonggon Yoo
2022-11-14 14:47                 ` Hyeonggon Yoo
2022-11-14 14:47                 ` Hyeonggon Yoo
2022-11-15  4:24                 ` Damien Le Moal
2022-11-15  4:24                   ` Damien Le Moal
2022-11-15  4:24                   ` Damien Le Moal
2022-11-15  4:24                   ` Damien Le Moal
2022-11-15  4:28                   ` Damien Le Moal
2022-11-15  4:28                     ` Damien Le Moal
2022-11-15  4:28                     ` Damien Le Moal
2022-11-15  4:28                     ` Damien Le Moal
2022-11-16  7:57                     ` Matthew Wilcox
2022-11-16  7:57                       ` Matthew Wilcox
2022-11-16  7:57                       ` Matthew Wilcox
2022-11-16  7:57                       ` Matthew Wilcox
2022-11-16  8:02                       ` Damien Le Moal
2022-11-16  8:02                         ` Damien Le Moal
2022-11-16  8:02                         ` Damien Le Moal
2022-11-16  8:02                         ` Damien Le Moal
2022-11-16 17:51                   ` Vlastimil Babka
2022-11-16 17:51                     ` Vlastimil Babka
2022-11-16 17:51                     ` Vlastimil Babka
2022-11-16 17:51                     ` Vlastimil Babka
2022-11-17  0:22                     ` Damien Le Moal
2022-11-17  0:22                       ` Damien Le Moal
2022-11-17  0:22                       ` Damien Le Moal
2022-11-17  0:22                       ` Damien Le Moal
2022-11-21  4:30                     ` Damien Le Moal
2022-11-21  4:30                       ` Damien Le Moal
2022-11-21  4:30                       ` Damien Le Moal
2022-11-21  4:30                       ` Damien Le Moal
2022-11-21 17:02                       ` Vlastimil Babka
2022-11-21 17:02                         ` Vlastimil Babka
2022-11-21 17:02                         ` Vlastimil Babka
2022-11-21 17:02                         ` Vlastimil Babka
2022-11-14 11:50             ` Hyeonggon Yoo
2022-11-14 11:50               ` Hyeonggon Yoo
2022-11-14 11:50               ` Hyeonggon Yoo
2022-11-14 11:50               ` Hyeonggon Yoo
2022-11-09 20:56 Paul Cercueil
2022-11-09 21:39 ` Linus Torvalds
2022-11-09 23:48   ` Aaro Koskinen
2022-11-09 23:51     ` Aaro Koskinen
2022-11-10  4:40     ` Theodore Ts'o
2022-11-10  7:31       ` Vlastimil Babka
2022-11-10  7:54         ` Feng Tang
2022-11-10 16:20         ` Matthew Wilcox
2022-11-11  9:37           ` David Laight

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=20221109155008.GC307514@darkstar.musicnaut.iki.fi \
    --to=aaro.koskinen@iki.fi \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=dalias@libc.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jmkrzyszt@gmail.com \
    --cc=jonas@southpole.se \
    --cc=josh@joshtriplett.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=openrisc@lists.librecores.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=rkovhaev@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shc_work@mail.ru \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=tony@atomide.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=ysato@users.sourceforge.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.