• Josef Bacik's avatar
    btrfs: improve preemptive background space flushing · 576fa348
    Josef Bacik authored
    Currently if we ever have to flush space because we do not have enough
    we allocate a ticket and attach it to the space_info, and then
    systematically flush things in the filesystem that hold space
    reservations until our space is reclaimed.
    
    However this has a latency cost, we must go to sleep and wait for the
    flushing to make progress before we are woken up and allowed to continue
    doing our work.
    
    In order to address that we used to kick off the async worker to flush
    space preemptively, so that we could be reclaiming space hopefully
    before any tasks needed to stop and wait for space to reclaim.
    
    When I introduced the ticketed ENOSPC stuff this broke slightly in the
    fact that we were using tickets to indicate if we were done flushing.
    No tickets, no more flushing.  However this meant that we essentially
    never preemptively flushed.  This caused a write performance regression
    that Nikolay noticed in an unrelated patch that removed the committing
    of the transaction during btrfs_end_transaction.
    
    The behavior that happened pre that patch was btrfs_end_transaction()
    would see that we were low on space, and it would commit the
    transaction.  This was bad because in this particular case you could end
    up with thousands and thousands of transactions being committed during
    the 5 minute reproducer.  With the patch to remove this behavior we got
    much more sane transaction commits, but we ended up slower because we
    would write for a while, flush, write for a while, flush again.
    
    To address this we need to reinstate a preemptive flushing mechanism.
    However it is distinctly different from our ticketing flushing in that
    it doesn't have tickets to base it's decisions on.  Instead of bolting
    this logic into our existing flushing work, add another worker to handle
    this preemptive flushing.  Here we will attempt to be slightly
    intelligent about the things that we flushing, attempting to balance
    between whichever pool is taking up the most space.
    Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
    Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    576fa348
space-info.c 49.9 KB