linux-kernel - RE: Do we really need SLOB nowdays?

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]

Message-ID: <7829ee15074448d5a7cec1a0e3c352d4@AcuMS.aculab.com>
Date:   Fri, 18 Feb 2022 16:10:28 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Hyeonggon Yoo' <42.hyeyoo@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>
CC:     Christoph Lameter <cl@...two.org>,
        Matthew Wilcox <willy@...radead.org>,
        Christoph Lameter <cl@...two.de>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: RE: Do we really need SLOB nowdays?

From: Hyeonggon Yoo
> Sent: 18 February 2022 10:13
...
> I think SLUB can be memory-efficient as SLOB.
> Is SLOB (Address-Ordered next^Wfirst fit) stronger to fragmentation than SLUB?

Dunno, but I had to patch the vxworks malloc to use 'best fit'
because 'first fit' based on a fifo free list was really horrid.

I can't imagine an address ordered 'first fit' really being that much better.

There are probably a lot more allocs and frees than the kernel used to have.

Also isn't the performance of a 'first fit' going to get horrid
when there are a lot of small items on the free list.

Does SLUB split pages into 3s and 5s (on cache lime boundaries)
as well as powers of 2?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)