Re: slub bulk alloc: Extract objects from the per cpu slab

[Christoph Lameter <cl@linux.com>]

On Wed, 8 Apr 2015, Andrew Morton wrote:

> On Wed, 8 Apr 2015 13:13:29 -0500 (CDT) Christoph Lameter <cl@linux.com> wrote:
>
> > First piece: accelleration of retrieval of per cpu objects
> >
> >
> > If we are allocating lots of objects then it is advantageous to
> > disable interrupts and avoid the this_cpu_cmpxchg() operation to
> > get these objects faster. Note that we cannot do the fast operation
> > if debugging is enabled.
>
> Why can't we do it if debugging is enabled?

We would have to add extra code to do all the debugging checks. And it
would not be fast anyways.

> > Allocate as many objects as possible in the fast way and then fall
> > back to the generic implementation for the rest of the objects.
>
> Seems sane.  What's the expected success rate of the initial bulk
> allocation attempt?

This is going to increase as we add more capabilities. I have a second
patch here that extends the fast allocation to the per cpu partial pages.

> > +		c->tid = next_tid(c->tid);
> > +
> > +		local_irq_enable();
> > +	}
> > +
> > +	return __kmem_cache_alloc_bulk(s, flags, size, p);
>
> This kmem_cache_cpu.tid logic is a bit opaque.  The low-level
> operations seem reasonably well documented but I couldn't find anywhere
> which tells me how it all actually works - what is "disambiguation
> during cmpxchg" and how do we achieve it?

This is used to force a retry in slab_alloc_node() if preemption occurs
there. We are modifying the per cpu state thus a retry must be forced.

> I'm in two minds about putting
> slab-infrastructure-for-bulk-object-allocation-and-freeing-v3.patch and
> slub-bulk-alloc-extract-objects-from-the-per-cpu-slab.patch into 4.1.
> They're standalone (ie: no in-kernel callers!) hence harmless, and
> merging them will make Jesper's life a bit easier.  But otoh they are
> unproven and have no in-kernel callers, so formally they shouldn't be
> merged yet.  I suppose we can throw them away again if things don't
> work out.

Can we keep them in -next and I will add patches as we go forward? There
was already a lot of discussion before and I would like to go
incrementally adding methods to do bulk extraction from the various
control structures that we have holding objects.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>