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: 26+ 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 ` [Cluster-devel] [PATCH V9 12/19] block: allow bio_for_each_segment_all() to iterate over multi-page bvec Ming Lei
2018-11-13 15:14 ` Ming Lei
2018-11-13 15:14 ` 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 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.