linux-kernel - Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree

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-next>] [day] [month] [year] [list]

Date:	Tue, 8 May 2007 19:23:08 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	akpm@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, clameter@....com
Subject: Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree

On Tue, May 08, 2007 at 04:02:20PM -0700, akpm@...ux-foundation.org wrote:
>  	bool "SLOB (Simple Allocator)"
>  	help
>  	   SLOB replaces the SLAB allocator with a drastically simpler
>  	   allocator.  SLOB is more space efficient that SLAB but does not
> -	   scale well (single lock for all operations) and is more susceptible
> -	   to fragmentation. SLOB it is a great choice to reduce
> -	   memory usage and code size for embedded systems.
> +	   scale well (single lock for all operations) and is also highly
> +	   susceptible to fragmentation. SLUB can accomplish a higher object
> +	   density. It is usually better to use SLUB instead of SLOB.

This isn't accurate.

First, SLOB no longer runs on SMP because SLAB grew some RCU-related
hair. So it now effectively has no locks at all! 

Second, I think the fragmentation issues are exaggerated. Before SLAB
was introduced, Linux's kmalloc was the moral equivalent of SLOB
(without SLAB emulation) and fragmentation was not the driving force
for replacement. Small Linux 1.x machines frequently had uptimes of 1+
years without fragmenting to death. Instead, it was performance with
large amounts of RAM - the old kmalloc (and SLOB) have performance
proportional to memory size.

Third, I don't think it's possible even in theory for a SLAB-like
allocator to be as efficient as SLOB simply due to the constraints of
putting only objects of the same size on a given page. So consider me
skeptical on the density claim.

It is usually better to use SLUB simply because you're more likely to
have 1GB of RAM rather than 4MB.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/