On Wed, 8 Apr 2015, Andrew Morton wrote: > On Wed, 8 Apr 2015 13:13:29 -0500 (CDT) Christoph Lameter <cl@xxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>