On Thu, 17 Sep 2015, Jesper Dangaard Brouer wrote: > What I'm proposing is keeping interrupts on, and then simply cmpxchg > e.g 2 slab-pages out of the SLUB allocator (which the SLUB code calls > freelist's). The bulk call now owns these freelists, and returns them > to the caller. The API caller gets some helpers/macros to access > objects, to shield him from the details (of SLUB freelist's). > > The pitfall with this API is we don't know how many objects are on a > SLUB freelist. And we cannot walk the freelist and count them, because > then we hit the problem of memory/cache stalls (that we are trying so > hard to avoid). If you get a fresh page from the page allocator then you know how many objects are available in a slab page. There is also a counter in each slab page for the objects allocated. The number of free object is page->objects - page->inuse. This is only true for a lockec cmpxchg. The unlocked cmpxchg used for the per cpu freelist does not use the counters in the page struct. -- 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>