2012/6/10 JoonSoo Kim <js1304@xxxxxxxxx>: > 2012/6/9 Christoph Lameter <cl@xxxxxxxxx>: >> On Sat, 9 Jun 2012, Joonsoo Kim wrote: >> >>> Current implementation of deactivate_slab() which deactivate >>> freelist of kmem_cache_cpu one by one is inefficient. >>> This patch changes it to deactivate freelist all at once. >>> But, there is no overall performance benefit, >>> because deactivate_slab() is invoked infrequently. >> >> Hmm, deactivate freelist can race with slab_free. Need to look at this in >> detail. > > Implemented logic is nearly same as previous one. > I just merge first step of previous deactivate_slab() with second one. > In case of failure of cmpxchg_double_slab(), reloading page->freelist, > page->counters and recomputing inuse > ensure that race with slab_free() cannot be possible. > In case that we need a lock, try to get a lock before invoking > cmpxchg_double_slab(), > so race with slab_free cannot be occured too. > > Above is my humble opinion, please give me some comments. Hi Pekka and Christoph. Could you give me some comments about this, please? -- 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>