diff options
author | Nick Piggin <npiggin@suse.de> | 2010-01-27 22:27:40 +1100 |
---|---|---|
committer | Pekka Enberg <penberg@cs.helsinki.fi> | 2010-01-30 15:02:39 +0200 |
commit | 44b57f1cc72a4a30b31f11b07a927d1534f1b93d (patch) | |
tree | 78e38b52bedf86446161e9df0cfbb2b7b4bc6dd8 /fs/ufs/file.c | |
parent | 7284ce6c9f6153d1777df5f310c959724d1bd446 (diff) | |
download | kernel_samsung_tuna-44b57f1cc72a4a30b31f11b07a927d1534f1b93d.zip kernel_samsung_tuna-44b57f1cc72a4a30b31f11b07a927d1534f1b93d.tar.gz kernel_samsung_tuna-44b57f1cc72a4a30b31f11b07a927d1534f1b93d.tar.bz2 |
slab: fix regression in touched logic
When factoring common code into transfer_objects in commit 3ded175 ("slab: add
transfer_objects() function"), the 'touched' logic got a bit broken. When
refilling from the shared array (taking objects from the shared array), we are
making use of the shared array so it should be marked as touched.
Subsequently pulling an element from the cpu array and allocating it should
also touch the cpu array, but that is taken care of after the alloc_done label.
(So yes, the cpu array was getting touched = 1 twice).
So revert this logic to how it worked in earlier kernels.
This also affects the behaviour in __drain_alien_cache, which would previously
'touch' the shared array and now does not. I think it is more logical not to
touch there, because we are pushing objects into the shared array rather than
pulling them off. So there is no good reason to postpone reaping them -- if the
shared array is getting utilized, then it will get 'touched' in the alloc path
(where this patch now restores the touch).
Acked-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Diffstat (limited to 'fs/ufs/file.c')
0 files changed, 0 insertions, 0 deletions