linux-kernel - Re: [PATCH 00/12] Introduce CONFIG_SLUB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Nov 2022 18:15:39 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Vlastimil Babka" <vbabka@...e.cz>,
        "Christoph Lameter" <cl@...ux.com>,
        "David Rientjes" <rientjes@...gle.com>,
        "Joonsoo Kim" <iamjoonsoo.kim@....com>,
        "Pekka Enberg" <penberg@...nel.org>
Cc:     "Hyeonggon Yoo" <42.hyeyoo@...il.com>,
        "Roman Gushchin" <roman.gushchin@...ux.dev>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Matthew Wilcox" <willy@...radead.org>, patches@...ts.linux.dev,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        "Aaro Koskinen" <aaro.koskinen@....fi>,
        "Christophe Leroy" <christophe.leroy@...roup.eu>,
        "Conor Dooley" <conor@...nel.org>,
        "Damien Le Moal" <damien.lemoal@...nsource.wdc.com>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        "Janusz Krzysztofik" <jmkrzyszt@...il.com>,
        "Jonas Bonn" <jonas@...thpole.se>,
        "Josh Triplett" <josh@...htriplett.org>,
        "Kees Cook" <keescook@...omium.org>,
        linux-arm-kernel@...ts.infradead.org,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        linux-riscv@...ts.infradead.org, linux-sh@...r.kernel.org,
        openrisc@...ts.librecores.org, "Rich Felker" <dalias@...c.org>,
        "Russell King" <linux@...linux.org.uk>,
        "Stafford Horne" <shorne@...il.com>,
        "Stefan Kristiansson" <stefan.kristiansson@...nalahti.fi>,
        "Tony Lindgren" <tony@...mide.com>,
        "Yoshinori Sato" <ysato@...rs.sourceforge.jp>
Subject: Re: [PATCH 00/12] Introduce CONFIG_SLUB_TINY and deprecate SLOB

On Tue, Nov 22, 2022, at 17:59, Vlastimil Babka wrote:
> On 11/22/22 17:33, Arnd Bergmann wrote:
>> On Mon, Nov 21, 2022, at 18:11, Vlastimil Babka wrote:
>> I can imagine those machines wanting to use sysfs in general
>> but not for the slab caches, so having a separate knob to
>> configure out the sysfs stuff could be useful without having
>> to go all the way to SLUB_TINY.
>
> Right, but AFAIK that wouldn't save much except some text size and kobjects,
> so probably negligible for >32MB?

Makes sense, I assume you have a better idea of how much this
could save. I'm not at all worried about the .text size, but
my initial guess was that the metadata for sysfs would be
noticeable.

>> For the options that trade off performance against lower
>> fragmentation (MIN/MAX_PARTIAL, KMALLOC_RECLAIM, percpu
>> slabs), I wonder if it's possible to have a boot time
>> default based on the amount of RAM per CPU to have a better
>> tuned system on most cases, rather than having to go
>> to one extreme or the other at compile time.
>
> Possible for some of these things, but for others that brings us back to the
> question what are the actual observed issues. If it's low memory in absolute
> number of pages, these can help, but if it's fragmentation (and the kind if
> RAM sizes should have page grouping by mobility enabled), ditching e.g. the
> KMALLOC_RECLAIM could make it worse. Unfortunately some of these tradeoffs
> can be rather unpredictable.

Are there any obvious wins on memory uage? I would guess that it
would be safe to e.g. ditch percpu slabs when running with less
128MB per CPU, and the MIN/MAX_PARTIAL values could easily
be a function of the number of pages in total or per cpu,
whichever makes most sense. As a side-effect, those could also
grow slightly larger on huge systems by scaling them with
log2(totalpages).

     Arnd