xfs
[Top] [All Lists]

[XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-r

To: xfs@xxxxxxxxxxx
Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.28-rc3-9167-g0335cb7
From: xfs@xxxxxxxxxxx
Date: Fri, 9 Jan 2009 00:19:51 -0600
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@xxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>

commit 0087167c9d5b1273e7e6bbe39a9ab13bdb9a39bb
Author: Nick Piggin <npiggin@xxxxxxx>
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@xxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>

commit 958f8c0e4fc311e23a40635a530c01aec366a6e8
Author: Nick Piggin <npiggin@xxxxxxx>
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@xxxxxxx>
    Reviewed-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Lachlan McIlroy <lachlan@xxxxxxx>

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

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

<Prev in Thread] Current Thread [Next in Thread>