On Wed, 21 Dec 2005, Nick Piggin wrote:
> Steven Rostedt wrote:
>
> > That looks like quite an undertaking, but may be well worth it. I think
> > Linux's memory management is starting to show it's age. It's been
>
> What do you mean by this? ie. what parts of it are a problem, and why?
>
> I think that replacing the buddy allocator probably wouldn't be a good
> idea because it is really fast and simple for page sized allocations which
> are the most common, and it is good at naturally avoiding external
> fragmentation. Internal fragmentation is not much of a problem because it
> is handled by slab.
Actually, I wasn't talking about the buddy allocator, since it is probably
the best backend allocator to have. I actually like it alot and it
doesn't seem to have a problem.
But the slab code has gotten more complex, and probably too feature full.
And I'm afraid that Christoph Lameter may be right, in that we could go to
another allocation scheme and after adding all the features that the slab
has, we would be just as complex.
>
> I can't see how replacing the buddy allocator with a completely agnostic
> range allocator could be a win at all.
That part I didn't agree with (replacing the buddy system I mean).
>
> Perhaps it would make more sense for bootmem, resources, vmalloc, etc. and
> I guess that is what Matt is suggesting.
I'd still add slab there, but as I said above, anything else may become
too complex. Although, playing with this Magazine thingy is starting to
look interesting!
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
