From: David Sterba <dsterba@suse.cz>
To: Dennis Zhou <dennis@kernel.org>
Cc: David Sterba <dsterba@suse.com>, Chris Mason <clm@fb.com>,
Josef Bacik <josef@toxicpanda.com>,
Omar Sandoval <osandov@osandov.com>,
kernel-team@fb.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 00/22] btrfs: async discard support
Date: Fri, 15 Nov 2019 18:40:34 +0100 [thread overview]
Message-ID: <20191115174034.GD3001@twin.jikos.cz> (raw)
In-Reply-To: <cover.1571865774.git.dennis@kernel.org>
On Wed, Oct 23, 2019 at 06:52:54PM -0400, Dennis Zhou wrote:
> Data:
> On a number of webservers, I collected data every minute accounting the
> time we spent in btrfs_finish_extent_commit() (col. 1) and in
> btrfs_commit_transaction() (col. 2). btrfs_finish_extent_commit() is
> where we discard extents synchronously before returning them to the
> free space cache.
>
> discard=sync:
> p99 total per minute p99 total per minute
> Drive | extent_commit() (ms) | commit_trans() (ms)
> ---------------------------------------------------------------
> Drive A | 434 | 1170
> Drive B | 880 | 2330
> Drive C | 2943 | 3920
> Drive D | 4763 | 5701
>
> discard=async:
> p99 total per minute p99 total per minute
> Drive | extent_commit() (ms) | commit_trans() (ms)
> --------------------------------------------------------------
> Drive A | 134 | 956
> Drive B | 64 | 1972
> Drive C | 59 | 1032
> Drive D | 62 | 1200
>
> While it's not great that the stats are cumulative over 1m, all of these
> servers are running the same workload and and the delta between the two
> are substantial. We are spending significantly less time in
> btrfs_finish_extent_commit() which is responsible for discarding.
Nice, thanks for getting the numbers. I think we can slap them to the
patch that introduceds async discard which is 5/22.
I went through the patchset, looks good, though I'm sure I missed some
small things, it's a lot of code. I'm going to add it first thing to 5.6
patch queue. There are some minor conflicts with patches in 5.5 queue,
so this will need to be sorted. I've seen some feedback to address,
it would be IMHO best to resend the whole series. Thanks.
prev parent reply other threads:[~2019-11-15 17:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 22:52 [PATCH v2 00/22] btrfs: async discard support Dennis Zhou
2019-10-23 22:52 ` [PATCH 01/22] bitmap: genericize percpu bitmap region iterators Dennis Zhou
2019-10-23 22:52 ` [PATCH 02/22] btrfs: rename DISCARD opt to DISCARD_SYNC Dennis Zhou
2019-10-23 22:52 ` [PATCH 03/22] btrfs: keep track of which extents have been discarded Dennis Zhou
2019-11-08 19:05 ` Josef Bacik
2019-11-11 17:20 ` Dennis Zhou
2019-10-23 22:52 ` [PATCH 04/22] btrfs: keep track of cleanliness of the bitmap Dennis Zhou
2019-11-08 19:12 ` Josef Bacik
2019-10-23 22:52 ` [PATCH 05/22] btrfs: add the beginning of async discard, discard workqueue Dennis Zhou
2019-11-11 18:49 ` David Sterba
2019-10-23 22:53 ` [PATCH 06/22] btrfs: handle empty block_group removal Dennis Zhou
2019-11-08 19:19 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 07/22] btrfs: discard one region at a time in async discard Dennis Zhou
2019-11-08 19:27 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 08/22] btrfs: add removal calls for sysfs debug/ Dennis Zhou
2019-11-08 19:28 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 09/22] btrfs: make UUID/debug have its own kobject Dennis Zhou
2019-11-08 19:29 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 10/22] btrfs: add discard sysfs directory Dennis Zhou
2019-11-08 19:29 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 11/22] btrfs: track discardable extents for async discard Dennis Zhou
2019-10-23 22:53 ` [PATCH 12/22] btrfs: keep track of discardable_bytes Dennis Zhou
2019-11-08 19:31 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 13/22] btrfs: calculate discard delay based on number of extents Dennis Zhou
2019-10-23 22:53 ` [PATCH 14/22] btrfs: add bps discard rate limit Dennis Zhou
2019-11-08 19:41 ` Josef Bacik
2019-11-15 17:28 ` David Sterba
2019-10-23 22:53 ` [PATCH 15/22] btrfs: limit max discard size for async discard Dennis Zhou
2019-10-23 22:53 ` [PATCH 16/22] btrfs: make max async discard size tunable Dennis Zhou
2019-10-23 22:53 ` [PATCH 17/22] btrfs: have multiple discard lists Dennis Zhou
2019-11-08 19:44 ` Josef Bacik
2019-10-23 22:53 ` [PATCH 18/22] btrfs: only keep track of data extents for async discard Dennis Zhou
2019-11-08 19:46 ` Josef Bacik
2019-11-08 20:14 ` Dennis Zhou
2019-11-15 17:31 ` David Sterba
2019-10-23 22:53 ` [PATCH 19/22] btrfs: keep track of discard reuse stats Dennis Zhou
2019-10-23 22:53 ` [PATCH 20/22] btrfs: add async discard header Dennis Zhou
2019-10-23 22:53 ` [PATCH 21/22] btrfs: increase the metadata allowance for the free_space_cache Dennis Zhou
2019-10-23 22:53 ` [PATCH 22/22] btrfs: make smaller extents more likely to go into bitmaps Dennis Zhou
2019-11-15 17:40 ` David Sterba [this message]
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=20191115174034.GD3001@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dennis@kernel.org \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=osandov@osandov.com \
/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.