From: Mike Snitzer <snitzer@redhat.com>
To: Ming Lei <tom.leiming@gmail.com>
Cc: Jens Axboe <axboe@fb.com>,
"open list:SOFTWARE RAID (Multiple Disks) SUPPORT"
<linux-raid@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
"maintainer:DEVICE-MAPPER (LVM)" <dm-devel@redhat.com>,
linux-block <linux-block@vger.kernel.org>,
Alasdair Kergon <agk@redhat.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Shaohua Li <shli@kernel.org>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 09/60] dm: dm.c: replace 'bio->bi_vcnt == 1' with !bio_multiple_segments
Date: Wed, 2 Nov 2016 10:24:54 -0400 [thread overview]
Message-ID: <20161102142454.GA9263@redhat.com> (raw)
In-Reply-To: <CACVXFVNxwL1Dm9Mbf=YXpjV4X5G45Ed_TOE1A=wAORWkEdaHCA@mail.gmail.com>
On Wed, Nov 02 2016 at 3:56am -0400,
Ming Lei <tom.leiming@gmail.com> wrote:
> On Wed, Nov 2, 2016 at 11:09 AM, Kent Overstreet
> <kent.overstreet@gmail.com> wrote:
> > On Mon, Oct 31, 2016 at 08:29:01AM -0700, Christoph Hellwig wrote:
> >> On Sat, Oct 29, 2016 at 04:08:08PM +0800, Ming Lei wrote:
> >> > Avoid to access .bi_vcnt directly, because it may be not what
> >> > the driver expected any more after supporting multipage bvec.
> >> >
> >> > Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> >>
> >> It would be really nice to have a comment in the code why it's
> >> even checking for multiple segments.
> >
> > Or ideally refactor the code to not care about multiple segments at all.
>
> The check on 'bio->bi_vcnt == 1' is introduced in commit de3ec86dff160(dm:
> don't start current request if it would've merged with the previous), which
> fixed one performance issue.[1]
>
> Looks the idea of the patch is to delay dispatching the rq if it
> would've merged with previous request and the rq is small(single bvec).
> I guess the motivation is to try to increase chance of merging with the delay.
>
> But why does the code check on 'bio->bi_vcnt == 1'? Once the bio is
> submitted, .bi_vcnt isn't changed any more and merging doesn't change
> it too. So should the check have been on blk_rq_bytes(rq)?
>
> Mike, please correct me if my understanding is wrong.
>
>
> [1] https://www.redhat.com/archives/dm-devel/2015-March/msg00014.html
The patch was labored over for quite a while and is based on suggestions I
got from Jens when discussing a very problematic aspect of old
.request_fn request-based DM performance for a multi-threaded (64
threads) sequential IO benchmark (vdbench IIRC). The issue was reported
by NetApp.
The patch in question fixed the lack of merging that was seen with this
interleaved sequential IO benchmark. The lack of merging was made worse
if a DM multipath device had more underlying paths (e.g. 4 instead of 2).
As for your question, about using blk_rq_bytes(rq) vs 'bio->bi_vcnt == 1'
.. not sure how that would be a suitable replacement. But it has been a
while since I've delved into these block core merge details of old
.request_fn but _please_ don't change the logic of this code simply
because it is proving itself to be problematic for your current
patchset's cleanliness.
Mike
next prev parent reply other threads:[~2016-11-02 14:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-29 8:07 [PATCH 00/60] block: support multipage bvec Ming Lei
2016-10-29 8:08 ` [PATCH 02/60] block drivers: convert to bio_init_with_vec_table() Ming Lei
2016-10-29 8:08 ` [PATCH 06/60] bcache: debug: avoid to access .bi_io_vec directly Ming Lei
2016-10-29 8:08 ` [PATCH 07/60] dm: crypt: use bio_add_page() Ming Lei
2016-10-29 8:08 ` [PATCH 08/60] dm: use bvec iterator helpers to implement .get_page and .next_page Ming Lei
2016-10-29 8:08 ` [PATCH 09/60] dm: dm.c: replace 'bio->bi_vcnt == 1' with !bio_multiple_segments Ming Lei
2016-10-31 15:29 ` Christoph Hellwig
2016-10-31 22:59 ` Ming Lei
2016-11-02 3:09 ` Kent Overstreet
2016-11-02 7:56 ` Ming Lei
2016-11-02 14:24 ` Mike Snitzer [this message]
2016-11-02 23:47 ` Ming Lei
2016-10-29 8:08 ` [PATCH 21/60] bcache: comment on direct access to bvec table Ming Lei
2016-10-29 8:08 ` [PATCH 22/60] block: comment on bio_alloc_pages() Ming Lei
2016-10-29 8:08 ` [PATCH 24/60] md: set NO_MP for request queue of md Ming Lei
2016-10-29 8:08 ` [PATCH 29/60] dm: limit the max bio size as BIO_SP_MAX_SECTORS << SECTOR_SHIFT Ming Lei
2016-10-29 8:08 ` [PATCH 30/60] bcache: set flag of QUEUE_FLAG_SPLIT_MP Ming Lei
2016-10-29 8:08 ` [PATCH 39/60] bcache: debug: switch to bio_clone_sp() Ming Lei
2016-10-29 8:08 ` [PATCH 57/60] bcache: convert to bio_for_each_segment_all_rd() Ming Lei
2016-10-29 8:08 ` [PATCH 58/60] dm-crypt: " Ming Lei
[not found] ` <1477728600-12938-24-git-send-email-tom.leiming@gmail.com>
2016-10-29 15:29 ` [PATCH 23/60] block: introduce flag QUEUE_FLAG_NO_MP Christoph Hellwig
2016-10-29 22:20 ` Ming Lei
2016-10-31 15:25 ` [PATCH 00/60] block: support multipage bvec Christoph Hellwig
2016-10-31 22:52 ` 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=20161102142454.GA9263@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=axboe@fb.com \
--cc=dm-devel@redhat.com \
--cc=hch@infradead.org \
--cc=kent.overstreet@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=shli@kernel.org \
--cc=tom.leiming@gmail.com \
/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).