All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christoph Hellwig <hch@lst.de>, David Sterba <dsterba@suse.com>,
	Josef Bacik <josef@toxicpanda.com>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: cleanup btrfs bio handling, part 2 v3
Date: Thu, 5 May 2022 14:56:49 +0800	[thread overview]
Message-ID: <a6952ff4-1e4e-5650-7d57-8fd442e9d5aa@gmx.com> (raw)
In-Reply-To: <20220504122524.558088-1-hch@lst.de>



On 2022/5/4 20:25, Christoph Hellwig wrote:
> Hi all,
>
> this series removes the need to allocate a separate object for I/O
> completions for all read and some write I/Os, and reduced the memory
> usage of the low-level bios cloned by btrfs_map_bio by using plain bios
> instead of the much larger btrfs_bio.

The most important part of this series is the patch "btrfs: remove
btrfs_end_io_wq()" I guess.

As a guy growing up mostly reading btrfs code, the btrfs_end_io_wq()
function looks straightforward to me initially, just put everything into
wq context and call it a day.

But as I started to look into how other fses handle their delayed work,
the btrfs way turns more "unique" other than straightforward.


So yes, aligning us to other fses, by only delaying into wq context when
necessary, should be a good thing.
Not reducing the memory allocation for the btrfs_end_io_wq structure,
but also making the atomic part of the endio function executed with less
delay.

But here I'm not sure if the btrfs way is a legacy from the past, or has
some hidden intention (possible related to performance?).

So do you mind to do some basic benchmark for read and write and see how
the throughput and latency changed?
(I guess we can get slightly reduced latency without really damping
everything else).

With such benchmark the series would be more convincing, and I can learn
some tricks on how to do proper performance tests.


Also mentioning how other fses handling delayed work may help guys like
me to get an understanding of the more common practice used in other fses.

Thanks,
Qu
>
> Changes since v2:
>   - rebased to the latests misc-next tree
>   - fixed an incorrectly assigned bi_end_io handler in the raid56 code
>
> Changes since v1:
>   - rebased to the latests misc-next tree
>   - don't call destroy_workqueue on NULL workqueues
>   - drop a marginal and slightly controversial cleanup to btrfs_map_bio
>
> Diffstat:
>   compression.c |   41 +++++-------
>   compression.h |    7 +-
>   ctree.h       |   14 ++--
>   disk-io.c     |  148 +++++-----------------------------------------
>   disk-io.h     |   11 ---
>   extent_io.c   |   35 ++++-------
>   extent_io.h   |    1
>   inode.c       |  162 +++++++++++++++++++--------------------------------
>   raid56.c      |  109 +++++++++++++---------------------
>   super.c       |   13 ----
>   volumes.c     |  184 +++++++++++++++++++++++++++-------------------------------
>   volumes.h     |    8 ++
>   12 files changed, 262 insertions(+), 471 deletions(-)

  parent reply	other threads:[~2022-05-05  6:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04 12:25 cleanup btrfs bio handling, part 2 v3 Christoph Hellwig
2022-05-04 12:25 ` [PATCH 01/10] btrfs: don't double-defer bio completions for compressed reads Christoph Hellwig
2022-05-04 12:25 ` [PATCH 02/10] btrfs: move more work into btrfs_end_bioc Christoph Hellwig
2022-05-04 12:25 ` [PATCH 03/10] btrfs: cleanup btrfs_submit_dio_bio Christoph Hellwig
2022-05-04 12:25 ` [PATCH 04/10] btrfs: split btrfs_submit_data_bio Christoph Hellwig
2022-05-04 12:38   ` Qu Wenruo
2022-05-04 14:08     ` Christoph Hellwig
2022-05-04 22:41       ` Qu Wenruo
2022-05-04 22:44         ` Qu Wenruo
2022-05-05 15:08         ` Christoph Hellwig
2022-05-04 12:25 ` [PATCH 05/10] btrfs: defer I/O completion based on the btrfs_raid_bio Christoph Hellwig
2022-05-04 12:25 ` [PATCH 06/10] btrfs: don't use btrfs_bio_wq_end_io for compressed writes Christoph Hellwig
2022-05-11 19:20   ` Nikolay Borisov
2022-05-11 19:28     ` Nikolay Borisov
2022-05-12  5:56       ` Christoph Hellwig
2022-05-04 12:25 ` [PATCH 07/10] btrfs: centralize setting REQ_META Christoph Hellwig
2022-05-04 12:25 ` [PATCH 08/10] btrfs: remove btrfs_end_io_wq Christoph Hellwig
2022-05-05  2:34   ` Qu Wenruo
2022-05-05 15:09     ` Christoph Hellwig
2022-05-04 12:25 ` [PATCH 09/10] btrfs: refactor btrfs_map_bio Christoph Hellwig
2022-05-04 12:46   ` Qu Wenruo
2022-05-04 12:25 ` [PATCH 10/10] btrfs: do not allocate a btrfs_bio for low-level bios Christoph Hellwig
2022-05-05 11:23   ` Qu Wenruo
2022-05-05  6:56 ` Qu Wenruo [this message]
2022-05-05 15:11   ` cleanup btrfs bio handling, part 2 v3 Christoph Hellwig
2022-05-12  6:22     ` Anand Jain
2022-05-12  6:30       ` Anand Jain
2022-05-05 15:34   ` David Sterba

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=a6952ff4-1e4e-5650-7d57-8fd442e9d5aa@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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.