From: Ming Lei <ming.lei@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Ming Lei <ming.lei@redhat.com>, Christoph Hellwig <hch@lst.de>
Subject: [PATCH V9 01/19] block: introduce multi-page page bvec helpers
Date: Tue, 13 Nov 2018 23:14:47 +0800 [thread overview]
Message-ID: <20181113151505.15498-2-ming.lei@redhat.com> (raw)
In-Reply-To: <20181113151505.15498-1-ming.lei@redhat.com>
This patch introduces helpers of 'mp_bvec_iter_*' for multipage
bvec support.
The introduced helpers treate one bvec as real multi-page segment,
which may include more than one pages.
The existed helpers of bvec_iter_* are interfaces for supporting current
bvec iterator which is thought as single-page by drivers, fs, dm and
etc. These introduced helpers will build single-page bvec in flight, so
this way won't break current bio/bvec users, which needn't any change.
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
---
include/linux/bvec.h | 63 +++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 60 insertions(+), 3 deletions(-)
diff --git a/include/linux/bvec.h b/include/linux/bvec.h
index 02c73c6aa805..8ef904a50577 100644
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@ -23,6 +23,44 @@
#include <linux/kernel.h>
#include <linux/bug.h>
#include <linux/errno.h>
+#include <linux/mm.h>
+
+/*
+ * What is multi-page bvecs?
+ *
+ * - bvecs stored in bio->bi_io_vec is always multi-page(mp) style
+ *
+ * - bvec(struct bio_vec) represents one physically contiguous I/O
+ * buffer, now the buffer may include more than one pages after
+ * multi-page(mp) bvec is supported, and all these pages represented
+ * by one bvec is physically contiguous. Before mp support, at most
+ * one page is included in one bvec, we call it single-page(sp)
+ * bvec.
+ *
+ * - .bv_page of the bvec represents the 1st page in the mp bvec
+ *
+ * - .bv_offset of the bvec represents offset of the buffer in the bvec
+ *
+ * The effect on the current drivers/filesystem/dm/bcache/...:
+ *
+ * - almost everyone supposes that one bvec only includes one single
+ * page, so we keep the sp interface not changed, for example,
+ * bio_for_each_segment() still returns bvec with single page
+ *
+ * - bio_for_each_segment*() will be changed to return single-page
+ * bvec too
+ *
+ * - during iterating, iterator variable(struct bvec_iter) is always
+ * updated in multipage bvec style and that means bvec_iter_advance()
+ * is kept not changed
+ *
+ * - returned(copied) single-page bvec is built in flight by bvec
+ * helpers from the stored multipage bvec
+ *
+ * - In case that some components(such as iov_iter) need to support
+ * multi-page bvec, we introduce new helpers(mp_bvec_iter_*) for
+ * them.
+ */
/*
* was unsigned short, but we might as well be ready for > 64kB I/O pages
@@ -50,16 +88,35 @@ struct bvec_iter {
*/
#define __bvec_iter_bvec(bvec, iter) (&(bvec)[(iter).bi_idx])
-#define bvec_iter_page(bvec, iter) \
+#define mp_bvec_iter_page(bvec, iter) \
(__bvec_iter_bvec((bvec), (iter))->bv_page)
-#define bvec_iter_len(bvec, iter) \
+#define mp_bvec_iter_len(bvec, iter) \
min((iter).bi_size, \
__bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done)
-#define bvec_iter_offset(bvec, iter) \
+#define mp_bvec_iter_offset(bvec, iter) \
(__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_done)
+#define mp_bvec_iter_page_idx(bvec, iter) \
+ (mp_bvec_iter_offset((bvec), (iter)) / PAGE_SIZE)
+
+/*
+ * <page, offset,length> of single-page(sp) segment.
+ *
+ * This helpers are for building sp bvec in flight.
+ */
+#define bvec_iter_offset(bvec, iter) \
+ (mp_bvec_iter_offset((bvec), (iter)) % PAGE_SIZE)
+
+#define bvec_iter_len(bvec, iter) \
+ min_t(unsigned, mp_bvec_iter_len((bvec), (iter)), \
+ (PAGE_SIZE - (bvec_iter_offset((bvec), (iter)))))
+
+#define bvec_iter_page(bvec, iter) \
+ nth_page(mp_bvec_iter_page((bvec), (iter)), \
+ mp_bvec_iter_page_idx((bvec), (iter)))
+
#define bvec_iter_bvec(bvec, iter) \
((struct bio_vec) { \
.bv_page = bvec_iter_page((bvec), (iter)), \
--
2.9.5
next prev parent reply other threads:[~2018-11-13 15:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 15:14 [PATCH V9 00/19] block: support multi-page bvec Ming Lei
2018-11-13 15:14 ` Ming Lei [this message]
2018-11-13 15:14 ` [PATCH V9 02/19] block: introduce bio_for_each_bvec() Ming Lei
2018-11-13 15:14 ` [PATCH V9 03/19] block: use bio_for_each_bvec() to compute multi-page bvec count Ming Lei
2018-11-13 15:14 ` [PATCH V9 04/19] block: use bio_for_each_bvec() to map sg Ming Lei
2018-11-13 15:14 ` [PATCH V9 05/19] block: introduce bvec_last_segment() Ming Lei
2018-11-13 15:14 ` [PATCH V9 06/19] fs/buffer.c: use bvec iterator to truncate the bio Ming Lei
2018-11-13 15:14 ` [PATCH V9 07/19] btrfs: use bvec_last_segment to get bio's last page Ming Lei
2018-11-13 15:14 ` [PATCH V9 08/19] btrfs: move bio_pages_all() to btrfs Ming Lei
2018-11-13 15:14 ` [PATCH V9 09/19] block: introduce bio_bvecs() Ming Lei
2018-11-13 15:14 ` [PATCH V9 10/19] block: loop: pass multi-page bvec to iov_iter Ming Lei
2018-11-13 15:14 ` [PATCH V9 11/19] bcache: avoid to use bio_for_each_segment_all() in bch_bio_alloc_pages() Ming Lei
2018-11-13 15:14 ` [PATCH V9 12/19] block: allow bio_for_each_segment_all() to iterate over multi-page bvec Ming Lei
2018-11-13 15:14 ` [PATCH V9 13/19] iomap & xfs: only account for new added page Ming Lei
2018-11-13 15:15 ` [PATCH V9 14/19] block: enable multipage bvecs Ming Lei
2018-11-13 15:15 ` [PATCH V9 15/19] block: always define BIO_MAX_PAGES as 256 Ming Lei
2018-11-13 15:15 ` [PATCH V9 16/19] block: document usage of bio iterator helpers Ming Lei
2018-11-13 15:15 ` [PATCH V9 17/19] block: don't use bio->bi_vcnt to figure out segment number Ming Lei
2018-11-13 15:15 ` [PATCH V9 18/19] block: kill QUEUE_FLAG_NO_SG_MERGE Ming Lei
2018-11-13 15:15 ` [PATCH V9 19/19] block: kill BLK_MQ_F_SG_MERGE Ming Lei
2018-11-14 2:44 ` [PATCH V9 00/19] block: support multi-page bvec Dave Chinner
2018-11-14 2:57 ` Ming Lei
2018-11-14 15:22 ` Christoph Hellwig
2018-11-15 9:35 ` Ming Lei
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=20181113151505.15498-2-ming.lei@redhat.com \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@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 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).