From: Christoph Hellwig <hch@infradead.org>
To: Kent Overstreet <kmo@daterainc.com>
Cc: Christoph Hellwig <hch@infradead.org>,
axboe@kernel.dk, neilb@suse.de, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
linux-raid@vger.kernel.org
Subject: Re: [PATCH 0/22] Immutable biovecs, block layer changes
Date: Tue, 24 Sep 2013 04:00:12 -0700 [thread overview]
Message-ID: <20130924110012.GA7160@infradead.org> (raw)
In-Reply-To: <20130808211529.GB15409@kmo-pixel>
Just curious, what's the state of the remaining immutable bio work?
On Thu, Aug 08, 2013 at 02:15:29PM -0700, Kent Overstreet wrote:
> > What is preventing you from sending those out as well? While it's not
> > absolutely nessecary it would certainly be good if we'd avoid a struct
> > bio size regression.
>
> There's still some fairly significant changes, and I don't want to make
> too many invasive changes at once.
>
> Main thing is making generic_make_request() take arbitrary size bios.
> After this series that's just two simple patches, but then the changes
> to make use of that will be changing behaviour in non obvious ways.
>
> The way the merging changes work is it enables multi page bvecs - so a
> bvec can point to many physically contiguous pages. This moves segment
> merging to bio_add_page(), and gets rid of bi_phys_segments - now
> bi_vcnt == bi_phys_segments, we just split the bio if it's too big.
>
> Then, with bio_add_page() building up large bios and the block layer
> splitting them as necessary, there shouldn't be any need for segment
> merging across bios anymore (because generally when that would've
> happened before, now we'd just be sending one larger bio down).
>
> The remaining patches aren't terribly complicated though (less
> complicated than this patch series). Trickiest bit is multipage bvecs,
> and that's mostly just lots of code auditing - the way I convert
> existing code is by adding bio_for_each_page() - analagous to
> bio_for_each_segment, but giving you bvecs that point to single pages.
> So it's an easy conversion, just have to make sure nothing's missed.
---end quoted text---
next prev parent reply other threads:[~2013-09-24 11:00 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 21:54 [PATCH 0/22] Immutable biovecs, block layer changes Kent Overstreet
2013-08-07 21:54 ` [PATCH 01/22] block: Use rw_copy_check_uvector() Kent Overstreet
2013-08-07 21:54 ` [PATCH 02/22] block: Consolidate duplicated bio_trim() implementations Kent Overstreet
2013-08-07 21:54 ` [PATCH 03/22] bcache: Kill unaligned bvec hack Kent Overstreet
2013-08-07 21:54 ` [PATCH 04/22] block: Abstract out bvec iterator Kent Overstreet
2013-08-08 2:04 ` Ed Cashin
2013-08-09 0:09 ` Kent Overstreet
2013-08-09 0:59 ` Ed Cashin
2013-08-09 1:05 ` Kent Overstreet
2013-08-09 20:16 ` Ed Cashin
2013-08-13 14:03 ` Ed Cashin
2013-08-13 18:51 ` Kent Overstreet
2013-08-13 19:18 ` Ed L Cashin
2013-08-07 21:54 ` [PATCH 05/22] dm: Use bvec_iter for dm_bio_record() Kent Overstreet
2013-08-07 21:54 ` [PATCH 06/22] block: Convert bio_iovec() to bvec_iter Kent Overstreet
2013-08-07 21:54 ` [PATCH 07/22] block: Convert bio_for_each_segment() " Kent Overstreet
[not found] ` <1375912471-5106-1-git-send-email-kmo-PEzghdH756F8UrSeD/g0lQ@public.gmane.org>
2013-08-07 21:54 ` [PATCH 08/22] block: Immutable bio vecs Kent Overstreet
2013-08-07 21:54 ` [PATCH 09/22] block: Convert bio_copy_data() to bvec_iter Kent Overstreet
2013-08-07 21:54 ` [PATCH 10/22] bio-integrity: Convert " Kent Overstreet
2013-08-07 21:54 ` [PATCH 11/22] block: Kill bio_segments()/bi_vcnt usage Kent Overstreet
2013-08-07 21:54 ` [PATCH 12/22] block: Convert drivers to immutable biovecs Kent Overstreet
2013-08-07 21:54 ` [PATCH 13/22] ceph: Convert " Kent Overstreet
2013-08-07 21:54 ` [PATCH 14/22] block: Kill bio_iovec_idx(), __bio_iovec() Kent Overstreet
2013-08-07 21:54 ` [PATCH 15/22] rbd: Refactor bio cloning, don't clone biovecs Kent Overstreet
2013-08-07 21:54 ` [PATCH 16/22] dm: Refactor for new bio cloning/splitting Kent Overstreet
2013-09-28 4:59 ` Mike Snitzer
2013-10-03 3:17 ` Kent Overstreet
2013-10-03 3:23 ` Mike Snitzer
2013-10-03 21:45 ` Kent Overstreet
2013-10-03 22:50 ` Mike Snitzer
2013-10-04 17:07 ` Mike Snitzer
2013-10-07 0:14 ` Mike Snitzer
2013-10-11 4:13 ` Kent Overstreet
2013-10-11 21:16 ` Mike Snitzer
2013-10-11 22:11 ` Kent Overstreet
2013-08-07 21:54 ` [PATCH 17/22] block: Remove bi_idx hacks Kent Overstreet
2013-08-07 21:54 ` [PATCH 18/22] block: Generic bio chaining Kent Overstreet
2013-08-10 7:38 ` Kent Overstreet
2013-08-07 21:54 ` [PATCH 19/22] block: Rename bio_split() -> bio_pair_split() Kent Overstreet
2013-08-07 21:54 ` [PATCH 20/22] block: Introduce new bio_split() Kent Overstreet
2013-08-07 21:54 ` [PATCH 21/22] block: Kill bio_pair_split() Kent Overstreet
2013-08-07 21:54 ` [PATCH 22/22] block: Don't save/copy bvec array anymore, share when cloning Kent Overstreet
2013-08-08 15:09 ` [PATCH 0/22] Immutable biovecs, block layer changes Christoph Hellwig
2013-08-08 21:15 ` Kent Overstreet
2013-09-24 11:00 ` Christoph Hellwig [this message]
2013-09-24 13:20 ` Mike Snitzer
2013-09-24 14:29 ` Christoph Hellwig
2013-09-24 19:19 ` Kent Overstreet
2013-09-27 18:38 ` Mike Snitzer
2013-09-24 19:16 ` Kent Overstreet
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=20130924110012.GA7160@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=kmo@daterainc.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).