Messages in this thread | | | Date | Tue, 20 Dec 2005 21:41:19 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [PATCH RT 00/02] SLOB optimizations |
| |
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 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/
| |