linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ming Lin <mlin@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	Kent Overstreet <kent.overstreet@gmail.com>,
	Dongsu Park <dongsu.park@profitbricks.com>,
	Ming Lin <mlin@kernel.org>
Subject: [RFC PATCH v2 00/10] simplify block layer based on immutable biovecs
Date: Mon, 27 Apr 2015 23:48:27 -0700	[thread overview]
Message-ID: <1430203717-13307-1-git-send-email-mlin@kernel.org> (raw)

Dongsu sent v1 of this patchset.
https://lkml.org/lkml/2014/12/22/128

This is the second attempt of simplifying block layer based on immutable
biovecs. Immutable biovecs, implemented by Kent Overstreet, have been
available in mainline since v3.14. Its original goal was actually making
generic_make_request() accept arbitrarily sized bios, and pushing the
splitting down to the drivers or wherever it's required. See also
discussions in the past, [1] [2] [3].

This will bring not only performance improvements, but also a great amount
of reduction in code complexity all over the block layer. Performance gain
is possible due to the fact that bio_add_page() does not have to check
unnecesary conditions such as queue limits or if biovecs are mergeable.
Those will be delegated to the driver level. Kent already said that he
actually benchmarked the impact of this with fio on a micron p320h, which
showed definitely a positive impact.

Moreover, this patchset also allows a lot of code to be deleted, mainly
because of removal of merge_bvec_fn() callbacks. We have been aware that
it has been always a delicate issue for stacking block drivers (e.g. md
and bcache) to handle merging bio consistently. This simplication will
help every individual block driver avoid having such an issue.

Patches are against 4.1-rc1. These are also available in my git repo at:
 
  https://git.kernel.org/cgit/linux/kernel/git/mlin/linux.git/log/?h=block-generic-req

This patchset is a prerequisite of other consecutive patchsets, e.g.
multipage biovecs, rewriting plugging, or rewriting direct-IO, which are
excluded this time. That means, this patchset should not bring any
regression to end-users.

I did some basic test. I'll run more tests to get some peformance numbers.

Comments are welcome.
Ming

[1] https://lkml.org/lkml/2014/11/23/263
[2] https://lkml.org/lkml/2013/11/25/732
[3] https://lkml.org/lkml/2014/2/26/618

Dongsu Park (1):
      Documentation: update notes in biovecs about arbitrarily sized bios

Kent Overstreet (9):
      block: make generic_make_request handle arbitrarily sized bios
      block: simplify bio_add_page()
      block: allow __blk_queue_bounce() to handle bios larger than BIO_MAX_PAGES
      bcache: clean up hacks around bio_split_pool
      btrfs: remove bio splitting and merge_bvec_fn() calls
      md/raid5: get rid of bio_fits_rdev()
      block: kill merge_bvec_fn() completely
      fs: use helper bio_add_page() instead of open coding on bi_io_vec
      md/raid10: make sync_request_write() call bio_copy_data()

 Documentation/block/biovecs.txt             |  10 +-
 block/bio.c                                 | 135 +++++++++++----------------
 block/blk-core.c                            |  19 ++--
 block/blk-merge.c                           | 140 ++++++++++++++++++++++++++--
 block/blk-mq.c                              |   2 +
 block/blk-settings.c                        |  22 -----
 block/bounce.c                              |  60 ++++++++++--
 drivers/block/drbd/drbd_int.h               |   1 -
 drivers/block/drbd/drbd_main.c              |   1 -
 drivers/block/drbd/drbd_req.c               |  37 +-------
 drivers/block/pktcdvd.c                     |  27 +-----
 drivers/block/ps3vram.c                     |   2 +
 drivers/block/rbd.c                         |  47 ----------
 drivers/block/rsxx/dev.c                    |   2 +
 drivers/block/umem.c                        |   2 +
 drivers/block/zram/zram_drv.c               |   2 +
 drivers/md/bcache/bcache.h                  |  18 ----
 drivers/md/bcache/io.c                      | 100 +-------------------
 drivers/md/bcache/journal.c                 |   4 +-
 drivers/md/bcache/request.c                 |  16 ++--
 drivers/md/bcache/super.c                   |  32 +------
 drivers/md/bcache/util.h                    |   5 +-
 drivers/md/bcache/writeback.c               |   4 +-
 drivers/md/dm-cache-target.c                |  21 -----
 drivers/md/dm-crypt.c                       |  16 ----
 drivers/md/dm-era-target.c                  |  15 ---
 drivers/md/dm-flakey.c                      |  16 ----
 drivers/md/dm-linear.c                      |  16 ----
 drivers/md/dm-log-writes.c                  |  16 ----
 drivers/md/dm-snap.c                        |  15 ---
 drivers/md/dm-stripe.c                      |  21 -----
 drivers/md/dm-table.c                       |   8 --
 drivers/md/dm-thin.c                        |  31 ------
 drivers/md/dm-verity.c                      |  16 ----
 drivers/md/dm.c                             | 122 +-----------------------
 drivers/md/dm.h                             |   2 -
 drivers/md/linear.c                         |  43 ---------
 drivers/md/md.c                             |  28 +-----
 drivers/md/md.h                             |  12 ---
 drivers/md/multipath.c                      |  21 -----
 drivers/md/raid0.c                          |  56 -----------
 drivers/md/raid0.h                          |   2 -
 drivers/md/raid1.c                          |  58 +-----------
 drivers/md/raid10.c                         | 139 ++-------------------------
 drivers/md/raid5.c                          |  55 +----------
 drivers/s390/block/dcssblk.c                |   2 +
 drivers/s390/block/xpram.c                  |   2 +
 drivers/staging/lustre/lustre/llite/lloop.c |   2 +
 fs/btrfs/volumes.c                          |  72 --------------
 fs/buffer.c                                 |   7 +-
 fs/jfs/jfs_logmgr.c                         |  14 +--
 include/linux/blkdev.h                      |  13 +--
 include/linux/device-mapper.h               |   4 -
 mm/page_io.c                                |   8 +-
 54 files changed, 322 insertions(+), 1219 deletions(-)


             reply	other threads:[~2015-04-28  6:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28  6:48 Ming Lin [this message]
2015-04-28  6:48 ` [PATCH 01/10] block: make generic_make_request handle arbitrarily sized bios Ming Lin
2015-04-28 11:43   ` Christoph Hellwig
2015-04-28 16:01     ` Keith Busch
2015-05-06  6:08     ` Ming Lin
2015-05-06  6:48       ` Christoph Hellwig
2015-05-06  7:13         ` Ming Lin
2015-04-28  6:48 ` [PATCH 02/10] block: simplify bio_add_page() Ming Lin
2015-04-28 12:12   ` Christoph Hellwig
2015-04-29  5:42     ` Ming Lin
2015-04-28  6:48 ` [PATCH 03/10] block: allow __blk_queue_bounce() to handle bios larger than BIO_MAX_PAGES Ming Lin
2015-04-28  6:48 ` [PATCH 04/10] bcache: clean up hacks around bio_split_pool Ming Lin
2015-04-28 12:14   ` Christoph Hellwig
2015-04-29  5:43     ` Ming Lin
2015-04-28  6:48 ` [PATCH 05/10] btrfs: remove bio splitting and merge_bvec_fn() calls Ming Lin
2015-04-28  6:48 ` [PATCH 06/10] md/raid5: get rid of bio_fits_rdev() Ming Lin
2015-04-28  6:48 ` [PATCH 07/10] block: kill merge_bvec_fn() completely Ming Lin
2015-04-28 17:31   ` Alasdair G Kergon
2015-04-29  6:32     ` Ming Lin
2015-04-28 22:09   ` NeilBrown
2015-05-04  7:47     ` Ming Lin
2015-05-06  7:10       ` Ming Lin
2015-05-06  7:26       ` Christoph Hellwig
2015-05-06 17:05         ` Ming Lin
2015-04-28  6:48 ` [PATCH 08/10] fs: use helper bio_add_page() instead of open coding on bi_io_vec Ming Lin
2015-04-28  6:48 ` [PATCH 09/10] md/raid10: make sync_request_write() call bio_copy_data() Ming Lin
2015-04-28  6:48 ` [PATCH 10/10] Documentation: update notes in biovecs about arbitrarily sized bios Ming Lin

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=1430203717-13307-1-git-send-email-mlin@kernel.org \
    --to=mlin@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dongsu.park@profitbricks.com \
    --cc=hch@lst.de \
    --cc=kent.overstreet@gmail.com \
    --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).