lkml.org 
[lkml]   [2010]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next] net: allocate skbs on local node
On Wed, 13 Oct 2010, Christoph Lameter wrote:

> > Will you be adding the extensive slub debugging to slab then? It would be
> > a shame to lose it because one allocator is chosen over another for
> > performance reasons and then we need to recompile to debug issues as they
> > arise.
>
> Well basically we would copy SLUB to SLAB apply unification patches to
> SLAB instead of SLUBB. We first have to make sure that the unified patches
> have the same performance as SLAB.
>

I see, so all of the development will be done in Pekka's tree on mm/slub.c
and then when we can see no performance regression compared to the slab
baseline, merge it into Linus' tree as mm/slab.c. I'm not exactly sure
how that set of diffs being sent to Linus would look.

Are the changes to slub in the unification patchset so intrusive that it
wouldn't be possible to isolate many of the features under #ifdef or
boot-time options in a single, truly unified, allocator? It seems like a
shame that we'll have two allocators where the base is the same and much
of the debugging code is the same.

> It maybe much better to isolate the debug features and general bootstrap
> from the particulars of the allocation strategy of either SLUB or SLAB.
> That way a common code base exists and it would be easier to add different
> allocation strategies.
>
> Basically have slab.c with the basic functions and then slab_queueing.c
> and slab_noqueue.c for SLAB/SLUB with the particulars of the allocation
> strategy?
>

I was going to mention that as an idea, but I thought storing the metadata
for certain debugging features might differ from the two allocators so
substantially that it would be even more convoluted and difficult to
maintain?


\
 
 \ /
  Last update: 2010-10-13 22:51    [W:0.057 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site