On Wed, 2011-09-07 at 23:01 +0800, Christoph Lameter wrote: > On Wed, 7 Sep 2011, Alex,Shi wrote: > > > In the per cpu partial slub, we may add a full page into node partial > > list. like the following scenario: > > > > cpu1 cpu2 > > in unfreeze_partials in __slab_alloc > > ... > > add_partial(n, page, 1); > > alloced from cpu partial, and > > set frozen = 1. > > second cmpxchg_double_slab() > > set frozen = 0 > > This scenario cannot happen as the frozen state confers ownership to a > cpu (like the cpu slabs). The cpu partial lists are different from the per > node partial lists and a slab on the per node partial lists should never > have the frozen bit set. oh, sorry, I am wrong here. Firstly, since unfreeze_partials only drain self cpu partial slabs, and __slab_alloc also only check self cpu partial. So, above scenario won't happen. Secondly, add_partial mean got the node list_lock already, so if __slab_alloc try to alloc from the node partial, it won't get the list_lock before cmpxchg finished. > > > If it happen, we'd better to skip the full page and to seek next slab in > > node partial instead of jump to other nodes. > > But I agree that the patch can be beneficial if acquire slab ever returns > a full page. That should not happen though. Is this theoretical or do you > have actual tests that show that this occurs? I didn't find a real case for this now. So, do you still like to pick up this as a defense for future more lockless usage? -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>