[XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-9167-g0335cb7

[xfs at oss.sgi.com]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "XFS development tree".

The branch, for-linus has been updated
  0335cb7 [XFS] Update maintainers
  0087167 [XFS] use scalable vmap API
  958f8c0 [XFS] remove old vmap cache
      from  058652a37dd9eac18d6b8c1a311137c679de9dae (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 0335cb76aa3fa913a2164bc9b669e5aef9d56fa3
Author: Lachlan McIlroy <lachlan at redback.melbourne.sgi.com>
Date:   Wed Dec 31 12:10:12 2008 +1100

    [XFS] Update maintainers
    
    New maintainer contact and new tree location.
    
    Reviewed-by: Bill O`Donnell <billodo at sgi.com>
    Signed-off-by: Lachlan McIlroy <lachlan at sgi.com>

commit 0087167c9d5b1273e7e6bbe39a9ab13bdb9a39bb
Author: Nick Piggin <npiggin at suse.de>
Date:   Tue Jan 6 14:43:09 2009 +1100

    [XFS] use scalable vmap API
    
    Implement XFS's large buffer support with the new vmap APIs. See the vmap
    rewrite (db64fe02) for some numbers. The biggest improvement that comes from
    using the new APIs is avoiding the global KVA allocation lock on every call.
    
    Signed-off-by: Nick Piggin <npiggin at suse.de>
    Reviewed-by: Christoph Hellwig <hch at infradead.org>
    Signed-off-by: Lachlan McIlroy <lachlan at sgi.com>

commit 958f8c0e4fc311e23a40635a530c01aec366a6e8
Author: Nick Piggin <npiggin at suse.de>
Date:   Tue Jan 6 14:40:44 2009 +1100

    [XFS] remove old vmap cache
    
    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 at suse.de>
    Reviewed-by: Christoph Hellwig <hch at infradead.org>
    Signed-off-by: Lachlan McIlroy <lachlan at sgi.com>

-----------------------------------------------------------------------

Summary of changes:
 MAINTAINERS                |    4 +-
 fs/xfs/linux-2.6/xfs_buf.c |   79 ++------------------------------------------
 2 files changed, 5 insertions(+), 78 deletions(-)


hooks/post-receive
-- 
XFS development tree