Messages in this thread | | | Date | Mon, 9 Jul 2007 15:52:32 -0500 | From | Matt Mackall <> | Subject | Re: [patch 09/10] Remove the SLOB allocator for 2.6.23 |
| |
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. - 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/
| |