]> git.baikalelectronics.ru Git - kernel.git/commit
xfs: remove old vmap cache
authorAlex Elder <aelder@sgi.com>
Tue, 16 Mar 2010 18:55:54 +0000 (18:55 +0000)
committerAlex Elder <aelder@sgi.com>
Tue, 16 Mar 2010 20:40:19 +0000 (15:40 -0500)
commit5685fa3299267c896ce231180cc5fd2f1702c6ca
tree497c3ab912f25994d7adc4c7a860cf01bb78c95c
parent7d758f45a3d15290986eed04eb85a1b7f6b8a152
xfs: remove old vmap cache

Re-apply a commit that had been reverted due to regressions
that have since been fixed.

    Original commit: 05bc52a2341b62edfaacd3e18d4e802016292d09
    Author: Nick Piggin <npiggin@suse.de>
    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 <npiggin@suse.de>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
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 <aelder@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
fs/xfs/linux-2.6/xfs_buf.c