Re: [RFC][PATCH] Check write to slab memory which freed alreadyusing mudflap

[David Rientjes]

On Fri, 10 Jul 2009, Nick Piggin wrote:

> What I would like to see is we eventualy make the hard decision
> and cull 2 of them. If SLQB is not clearly better (or, if it is
> clearly worse) than the other allocators and it can't be improved,
> then it has failed my goals for it and I would prefer to remove it
> from the tree.
> 

The design of slqb, to your credit, appears more extendable than slub and 
addressing issues such as the netperf regression (which only manifests 
noticeably on my systems with >= 16 cpus) should be easier since they 
won't be antagonist to the allocator's inherent design.

The reason why I'd like to see slqb merged as a non-default alternative is 
because it exposes the allocator to more benchmarking coverage than would 
be possible in any other environment and attracts much more attention to 
development for those who don't pull Pekka's tree directly.
--
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/