On Fri, 2 Jun 2017, Michael Ellerman wrote: > Hugh Dickins <hughd@xxxxxxxxxx> writes: > > On Thu, 1 Jun 2017, Christoph Lameter wrote: > >> > >> Ok so debugging was off but the slab cache has a ctor callback which > >> mandates that the free pointer cannot use the free object space when > >> the object is not in use. Thus the size of the object must be increased to > >> accomodate the freepointer. > > > > Thanks a lot for working that out. Makes sense, fully understood now, > > nothing to worry about (though makes one wonder whether it's efficient > > to use ctors on high-alignment caches; or whether an internal "zero-me" > > ctor would be useful). > > Or should we just be using kmem_cache_zalloc() when we allocate from > those slabs? > > Given all the ctor's do is memset to 0. I'm not sure. From a memory-utilization point of view, with SLUB, using kmem_cache_zalloc() there would certainly be better. But you may be forgetting that the constructor is applied only when a new slab of objects is allocated, not each time an object is allocated from that slab (and the user of those objects agrees to free objects back to the cache in a reusable state: zeroed in this case). So from a cpu-utilization point of view, it's better to use the ctor: it's saving you lots of redundant memsets. SLUB versus SLAB, cpu versus memory? Since someone has taken the trouble to write it with ctors in the past, I didn't feel on firm enough ground to recommend such a change. But it may be obvious to someone else that your suggestion would be better (or worse). Hugh -- 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>
