Messages in this thread | | | Date | Wed, 21 Dec 2005 07:36:07 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH RT 00/02] SLOB optimizations |
| |
* Steven Rostedt <rostedt@goodmis.org> wrote:
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=113510997009883&w=2 > > > > Quite a long list of unsupported features. These academic papers > > usually only focus on one thing. The SLAB allocator has to work > > for a variety of situations though. > > > > It would help to explain what ultimately will be better in the new slab > > allocator. The complexity could be taken care of by reorganizing the code. > > Honestly, what I would like is a simpler solution, whether we go with > a new approach or reorganize the current slab. I need to get -rt > working, and the code in slab is pulling my resources more than they > can extend. I'm capable to convert slab today as it is for RT but it > will probably take longer than I can afford.
please, lets let the -rt tree out of the equation. The SLAB code is fine on upstream, and it was a pure practical maintainance decision to go for SLOB in the -rt tree. Yes, the SLAB code is complex, but i could hardly list any complexity in it tht isnt justified with a performance argument. _Maybe_ the SLAB code could be further cleaned up, maybe it could even be replaced, but we'd have to see the patches first. In any case, the -rt tree is not an argument that matters.
Ingo - 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/
| |