All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fb.com>
To: <bo.li.liu@oracle.com>
Cc: <linux-btrfs@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [PATCH] Btrfs: track transid for delayed ref flushing
Date: Tue, 12 Apr 2016 13:55:28 -0400	[thread overview]
Message-ID: <570D3690.3010701@fb.com> (raw)
In-Reply-To: <20160412174312.GB3524@localhost.localdomain>

On 04/12/2016 01:43 PM, Liu Bo wrote:
> On Mon, Apr 11, 2016 at 05:37:40PM -0400, Josef Bacik wrote:
>> Using the offwakecputime bpf script I noticed most of our time was spent waiting
>> on the delayed ref throttling.  This is what is supposed to happen, but
>> sometimes the transaction can commit and then we're waiting for throttling that
>> doesn't matter anymore.  So change this stuff to be a little smarter by tracking
>> the transid we were in when we initiated the throttling.  If the transaction we
>> get is different then we can just bail out.  This resulted in a 50% speedup in
>> my fs_mark test, and reduced the amount of time spent throttling by 60 seconds
>> over the entire run (which is about 30 minutes).  Thanks,
>
> Does the bpf script show where it's waiting on?  delayed_refs spinlock?

We are waiting on the wait_for_completion() in 
btrfs_async_run_delayed_refs.  The script only catches where we're in 
TASK_UNINTERRUPTIBLE for longer than 100ms.

>
> Maybe we can make it even smarter.
>
> In __btrfs_end_transaction(), the only case it won't wait for running delayed refs
> is when trans is JOIN_NOLOCK or ATTACH and "must_run_delayed_refs = 2".
>
> In other cases, even we queue a work into helper worker to do async
> delayed refs processing, __btrfs_end_transaction() still waits there.
>
> Since it's a 50% speedup, it looks like at least 50% of __btrfs_end_transaction()
> are waiting for other trans's queued delayed refs, can we do the check
> a little bit earlier, in btrfs_async_run_delayed_refs()?

We'd have to start another transaction, we don't want to have to do 
that.  What I want to do later is have the flushing stuff running all 
the time, so we notice way sooner if we end up with a bunch of people 
all trying to throttle at once.  So we drop below the throttle watermark 
and everybody wakes up, instead of everybody does their work no matter 
what and then wakes up.  But this was quick and easy and I've got other 
stuff to do so this is what I posted ;).  Thanks,

Josef


  reply	other threads:[~2016-04-12 17:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11 21:37 [PATCH] Btrfs: track transid for delayed ref flushing Josef Bacik
2016-04-12 17:43 ` Liu Bo
2016-04-12 17:55   ` Josef Bacik [this message]
2016-04-27 13:59 ` Chris Mason
2016-04-27 22:29   ` David Sterba
2016-06-17 14:30     ` Chris Mason
2016-06-16  0:47   ` Liu Bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=570D3690.3010701@fb.com \
    --to=jbacik@fb.com \
    --cc=bo.li.liu@oracle.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.