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: <45a4b0ac2bac40a691b55ae9de5c6617@AcuMS.aculab.com>
Date:   Sat, 1 Apr 2023 22:04:26 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Christophe Leroy' <christophe.leroy@...roup.eu>,
        'Vlastimil Babka' <vbabka@...e.cz>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH] mm: remove all the slab allocators

From: Christophe Leroy
> Sent: 01 April 2023 19:45
> 
> Le 01/04/2023 à 20:33, David Laight a écrit :
> > From: Vlastimil Babka
> >> Sent: 32 March 2023 10:47
> >>
> >> As the SLOB removal is on track and the SLAB removal is planned, I have
> >> realized - why should we stop there and not remove also SLUB? What's a
> >> slab allocator good for in 2023? The RAM sizes are getting larger and
> >> the modules cheaper [1]. The object constructor trick was perhaps
> >> interesting in 1994, but not with contemporary CPUs. So all the slab
> >> allocator does today is just adding an unnecessary layer of complexity
> >> over the page allocator.
> >
> > Why stop there?
> > Remove kmalloc() completely.
> > With cheap memory isn't unreasonable to go back to compile-time
> > settable fixed size arrays for all items.
> > Should make 'use after free' much easier to track down.
> >
> 
> While at it, why not also increase the page size to hugepage size, that
> would allow us to remove all the complex THP logic, and would remove one
> level of page tables. I would also reduce TLB pressure.

Good idea, 4k pages were used on systems where the total system
memory was a few MB.
Memory system are now easily 1000x times larger - so why not 4MB
pages ....

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ