On Thu, 16 Aug 2012, Joonsoo Kim wrote: > When we try to free object, there is some of case that we need > to take a node lock. This is the necessary step for preventing a race. > After taking a lock, then we try to cmpxchg_double_slab(). > But, there is a possible scenario that cmpxchg_double_slab() is failed > with taking a lock. Following example explains it. > > CPU A CPU B > need lock > ... need lock > ... lock!! > lock..but spin free success > spin... unlock > lock!! > free fail > > In this case, retry with taking a lock is occured in CPU A. > I think that in this case for CPU A, > "release a lock first, and re-take a lock if necessary" is preferable way. > > There are two reasons for this. > > First, this makes __slab_free()'s logic somehow simple. > With this patch, 'was_frozen = 1' is "always" handled without taking a lock. > So we can remove one code path. > > Second, it may reduce lock contention. > When we do retrying, status of slab is already changed, > so we don't need a lock anymore in almost every case. > "release a lock first, and re-take a lock if necessary" policy is > helpful to this. > > Signed-off-by: Joonsoo Kim <js1304@xxxxxxxxx> > Cc: Christoph Lameter <cl@xxxxxxxxx> > Acked-by: Christoph Lameter <cl@xxxxxxxxx> Applied, thanks! -- 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>