Skip to content
  • Josef Bacik's avatar
    Btrfs: batch extent inserts/updates/deletions on the extent root · f3465ca4
    Josef Bacik authored
    
    
    While profiling the allocator I noticed a good amount of time was being spent in
    finish_current_insert and del_pending_extents, and as the filesystem filled up
    more and more time was being spent in those functions.  This patch aims to try
    and reduce that problem.  This happens two ways
    
    1) track if we tried to delete an extent that we are going to update or insert.
    Once we get into finish_current_insert we discard any of the extents that were
    marked for deletion.  This saves us from doing unnecessary work almost every
    time finish_current_insert runs.
    
    2) Batch insertion/updates/deletions.  Instead of doing a btrfs_search_slot for
    each individual extent and doing the needed operation, we instead keep the leaf
    around and see if there is anything else we can do on that leaf.  On the insert
    case I introduced a btrfs_insert_some_items, which will take an array of keys
    with an array of data_sizes and try and squeeze in as many of those keys as
    possible, and then return how many keys it was able to insert.  In the update
    case we search for an extent ref, update the ref and then loop through the leaf
    to see if any of the other refs we are looking to update are on that leaf, and
    then once we are done we release the path and search for the next ref we need to
    update.  And finally for the deletion we try and delete the extent+ref in pairs,
    so we will try to find extent+ref pairs next to the extent we are trying to free
    and free them in bulk if possible.
    
    This along with the other cluster fix that Chris pushed out a bit ago helps make
    the allocator preform more uniformly as it fills up the disk.  There is still a
    slight drop as we fill up the disk since we start having to stick new blocks in
    odd places which results in more COW's than on a empty fs, but the drop is not
    nearly as severe as it was before.
    
    Signed-off-by: default avatarJosef Bacik <jbacik@redhat.com>
    f3465ca4