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

[Matt Mackall <mpm@selenic.com>]

On Tue, May 08, 2007 at 04:02:20PM -0700, akpm@linux-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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/