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 <js1...@gmail.com> > Cc: Christoph Lameter <c...@linux.com> > Acked-by: Christoph Lameter <c...@linux.com>
Applied, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
