summaryrefslogtreecommitdiffstats
path: root/Kbuild
diff options
context:
space:
mode:
authorJoonsoo Kim <js1304@gmail.com>2012-08-16 00:02:40 +0900
committerPekka Enberg <penberg@kernel.org>2012-10-19 10:19:24 +0300
commit837d678dc264c797c16f81cf56f615f7544891c1 (patch)
tree9ed759efc6bb0e404a6e4faf576f50b4641011a3 /Kbuild
parentddffeb8c4d0331609ef2581d84de4d763607bd37 (diff)
downloadlinux-837d678dc264c797c16f81cf56f615f7544891c1.tar.bz2
slub: remove one code path and reduce lock contention in __slab_free()
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@gmail.com> Acked-by: Christoph Lameter <cl@linux.com> Signed-off-by: Pekka Enberg <penberg@kernel.org>
Diffstat (limited to 'Kbuild')
0 files changed, 0 insertions, 0 deletions