Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

[Matt Mackall <mpm@selenic.com>]

First, WTF wasn't I cc:ed on this? Are you actually trying to me make
me fuming mad?

On Sat, Jul 07, 2007 at 08:50:01PM -0700, Christoph Lameter wrote:
> Maintenance of slab allocators becomes a problem as new features for
> allocators are developed. The SLOB allocator in particular has been lagging
> behind in many ways in the past:
> 
> - Had no support for SLAB_DESTROY_BY_RCU for years (but no one noticed)

We've been over this 50 times. The target users were never affected.
And it's fixed. So why the HELL are you mentioning this again? 
 
> - Still has no support for slab reclaim counters. This may currently not
>   be necessary if one would restrict the supported configurations for
>   functionality relying on these. But even that has not been done.

We've been over this 50 times. Last time around, I inspected all the
code paths and demonstrated that despite your handwaving, IT DIDN'T
MATTER.

> The only current advantage over SLUB in terms of memory savings is through
> SLOBs kmalloc layout that is not power of two based like SLAB and SLUB which
> allows to eliminate some memory waste.
> 
> Through that SLOB has still a slight memory advantage over SLUB of ~350k in
> for a standard server configuration. It is likely that the savings are is
> smaller for real embedded configurations that have less functionality.

Sometimes I do not think there is a cluebat large enough for you. 350K
is FREAKING HUGE on a cell phone. That's most of a kernel!

-- 
Mathematics is the supreme nostalgia of our time.