aboutsummaryrefslogtreecommitdiff
path: root/scripts/basic/docproc.c
diff options
context:
space:
mode:
authorAlex Elder <[email protected]>2010-03-16 18:55:54 +0000
committerAlex Elder <[email protected]>2010-03-16 15:40:19 -0500
commitcd9640a70d542ca026a812ac34733799da0a39c9 (patch)
tree497c3ab912f25994d7adc4c7a860cf01bb78c95c /scripts/basic/docproc.c
parent57d54889cd00db2752994b389ba714138652e60c (diff)
xfs: remove old vmap cache
Re-apply a commit that had been reverted due to regressions that have since been fixed. Original commit: d2859751cd0bf586941ffa7308635a293f943c17 Author: Nick Piggin <[email protected]> Date: Tue, 6 Jan 2009 14:40:44 +1100 XFS's vmap batching simply defers a number (up to 64) of vunmaps, and keeps track of them in a list. To purge the batch, it just goes through the list and calls vunamp on each one. This is pretty poor: a global TLB flush is generally still performed on each vunmap, with the most expensive parts of the operation being the broadcast IPIs and locking involved in the SMP callouts, and the locking involved in the vmap management -- none of these are avoided by just batching up the calls. I'm actually surprised it ever made much difference. (Now that the lazy vmap allocator is upstream, this description is not quite right, but the vunmap batching still doesn't seem to do much). Rip all this logic out of XFS completely. I will improve vmap performance and scalability directly in subsequent patch. Signed-off-by: Nick Piggin <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Lachlan McIlroy <[email protected]> The only change I made was to use the "new" xfs_buf_is_vmapped() function in a place it had been open-coded in the original. Modified-by: Alex Elder <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Alex Elder <[email protected]>
Diffstat (limited to 'scripts/basic/docproc.c')
0 files changed, 0 insertions, 0 deletions