From: Nikolay Borisov <nborisov@suse.com>
To: Christoph Hellwig <hch@lst.de>, Chris Mason <clm@fb.com>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 05/11] btrfs: remove bioc->stripes_pending
Date: Thu, 14 Jul 2022 15:15:35 +0300 [thread overview]
Message-ID: <d8d787dc-a3be-9207-0f2d-3e089ea5b9ea@suse.com> (raw)
In-Reply-To: <20220713061359.1980118-6-hch@lst.de>
On 13.07.22 г. 9:13 ч., Christoph Hellwig wrote:
> The stripes_pending in the btrfs_io_context counts number of inflight
> low-level bios for an upper btrfs_bio. For reads this is generally
> one as reads are never cloned, while for writes we can trivially use
> the bio remaining mechanisms that is used for chained bios.
>
> To be able to make use of that mechanism, split out a separate trivial
> end_io handler for the cloned bios that does a minimal amount of error
> tracking and which then calls bio_endio on the original bio to transfer
> control to that, with the remaining counter making sure it is completed
> last. This then allows to merge btrfs_end_bioc into the original bio
> bi_end_io handler. To make this all work all error handling needs to
> happen through the bi_end_io handler, which requires a small amount
> of reshuffling in submit_stripe_bio so that the bio is cloned already
> by the time the suitability of the device is checked.
>
> This reduces the size of the btrfs_io_context and prepares splitting
> the btrfs_bio at the stripe boundary.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
next prev parent reply other threads:[~2022-07-14 12:15 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 6:13 btrfs I/O completion cleanup and single device I/O optimizations v2 Christoph Hellwig
2022-07-13 6:13 ` [PATCH 01/11] btrfs: don't call bioset_integrity_create for btrfs_bioset Christoph Hellwig
2022-07-13 6:13 ` [PATCH 02/11] btrfs: move btrfs_bio allocation to volumes.c Christoph Hellwig
2022-07-13 6:13 ` [PATCH 03/11] btrfs: pass the operation to btrfs_bio_alloc Christoph Hellwig
2022-07-13 6:13 ` [PATCH 04/11] btrfs: don't take a bio_counter reference for cloned bios Christoph Hellwig
2022-07-13 6:27 ` Johannes Thumshirn
2022-07-13 6:13 ` [PATCH 05/11] btrfs: remove bioc->stripes_pending Christoph Hellwig
2022-07-13 6:31 ` Johannes Thumshirn
2022-07-13 6:41 ` Johannes Thumshirn
2022-07-14 12:15 ` Nikolay Borisov [this message]
2022-07-13 6:13 ` [PATCH 06/11] btrfs: properly abstract the parity raid bio handling Christoph Hellwig
2022-07-13 6:13 ` [PATCH 07/11] btrfs: give struct btrfs_bio a real end_io handler Christoph Hellwig
2022-07-13 6:47 ` Johannes Thumshirn
2022-07-13 6:51 ` Christoph Hellwig
2022-07-13 6:13 ` [PATCH 08/11] btrfs: split submit_stripe_bio Christoph Hellwig
2022-07-13 6:46 ` Johannes Thumshirn
2022-07-13 6:50 ` Christoph Hellwig
2022-07-13 6:52 ` Johannes Thumshirn
2022-07-14 14:02 ` Nikolay Borisov
2022-07-13 6:13 ` [PATCH 09/11] btrfs: simplify the submit_stripe_bio calling convention Christoph Hellwig
2022-07-13 6:49 ` Johannes Thumshirn
2022-07-14 14:30 ` Nikolay Borisov
2022-07-13 6:13 ` [PATCH 10/11] btrfs: make the btrfs_io_context allocation in __btrfs_map_block optional Christoph Hellwig
2022-07-13 9:58 ` Johannes Thumshirn
2022-07-13 11:18 ` Christoph Hellwig
2022-07-15 8:30 ` Nikolay Borisov
2022-07-13 6:13 ` [PATCH 11/11] btrfs: stop allocation a btrfs_io_context for simple I/O Christoph Hellwig
2022-09-06 13:12 ` btrfs I/O completion cleanup and single device I/O optimizations v2 David Sterba
2022-09-07 9:08 ` Christoph Hellwig
2022-09-09 12:34 ` David Sterba
-- strict thread matches above, loose matches on Subject: below --
2022-08-06 8:03 btrfs I/O completion cleanup and single device I/O optimizations v3 Christoph Hellwig
2022-08-06 8:03 ` [PATCH 05/11] btrfs: remove bioc->stripes_pending Christoph Hellwig
2022-08-18 11:33 ` Anand Jain
2022-08-18 23:36 ` Anand Jain
2022-08-18 23:37 ` Anand Jain
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=d8d787dc-a3be-9207-0f2d-3e089ea5b9ea@suse.com \
--to=nborisov@suse.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=johannes.thumshirn@wdc.com \
--cc=josef@toxicpanda.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.