Re: [RFC PATCH] greatly reduce SLOB external fragmentation

[Pekka Enberg]

Hi Linus,

On Thu, Jul 31, 2008 at 1:00 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> I'm happy to hear that the thing worked, but I'm not sure how happy I
> should be about yet _another_ allocator. Will it ever end?

Oh, I didn't suggest this for merging. Just thought you'd be
interested to know that best-fit doesn't really do that much better
than what we have in the tree now. (Well, I was kinda hoping you'd
tell me why my implementation is wrong and you were right all along.)

On Thu, Jul 31, 2008 at 1:00 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> But seriously, it looks simple and small enough, so in that sense there
> doesn't seem to be a problem. But I really don't look forward to another
> one of these, at least not without somebody deciding that yes, we can
> prune one of the old ones as never being better. Hmm?

I think the current situation is bit unfortunate. SLOB doesn't want
cater for everybody (and probably can't do that either), SLAB sucks
for NUMA and embedded, and SLUB is too much of a "memory pig"
(although much less so than SLAB) to replace SLOB and it has that TPC
regression we don't have a test case for.

So while SLAB is (slowly) on it's way out, we really don't have a
strategy for SLOB/SLUB. I'm trying to come up with something that's
memory efficient first and then try to tune that for SMP and NUMA.
Looking at how tuned the fast-paths of SLAB and SLUB are (due to the
design), it seems unlikely that we can come up with anything that
could compete with them. But that doesn't mean we can't have fun
trying ;-).

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