From: Sagi Grimberg <sagig@dev.mellanox.co.il>
To: Ming Lei <ming.lei@canonical.com>, Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org
Cc: linux-block@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Kent Overstreet <kent.overstreet@gmail.com>,
Keith Busch <keith.busch@intel.com>,
Elliott Robert <elliott@hpe.com>
Subject: Re: [PATCH v1 0/4] block: fix bio_will_gap()
Date: Sun, 21 Feb 2016 11:41:00 +0200 [thread overview]
Message-ID: <56C9862C.70908@dev.mellanox.co.il> (raw)
In-Reply-To: <1455852022-14188-1-git-send-email-ming.lei@canonical.com>
> Hi Guys,
>
> The bio passed to bio_will_gap() may be fast cloned from upper
> layer(dm, md, bcache, fs, ...), or from bio splitting in block
> core. Unfortunately bio_will_gap() just figures out the last
> bvec via 'bi_io_vec[prev->bi_vcnt - 1]' directly, and this way
> is obviously wrong in case of fast-cloned bio.
>
> It is observed that lots of BIOs are still merged even if
> the virt boundary limit is violated by the merge, and the issue
> was reported from Sagi Grimberg.
>
> This patch introduces two helpers for getting the first and last
> bvec of one bio and applys them to fix the issue. Sagi tested
> the last patchset and confirmed the fix.
>
> V1:
> - get bvec directly for non-cloned bio
> - implement bio_get_last_bvec() with single bio_advance_iter(),
> and avoid to use bio_for_each_segment() which looks a bit inefficient
> - avoid to double check queue_virt_boundary() in bio_will_gap()
Thanks Ming,
Jens, can this make the next 4.5-rc since this regression was detected
in 4.5?
Thanks,
Sagi.
prev parent reply other threads:[~2016-02-21 18:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 3:20 [PATCH v1 0/4] block: fix bio_will_gap() Ming Lei
2016-02-19 3:20 ` [PATCH v1 1/4] block: bio: introduce helpers to get the 1st and last bvec Ming Lei
2016-02-21 9:38 ` Sagi Grimberg
2016-02-22 8:59 ` Christoph Hellwig
2016-02-19 3:20 ` [PATCH v1 2/4] block: check virt boundary in bio_will_gap() Ming Lei
2016-02-21 9:39 ` Sagi Grimberg
2016-02-22 9:00 ` Christoph Hellwig
2016-02-19 3:20 ` [PATCH v1 3/4] block: get the 1st and last bvec via helpers Ming Lei
2016-02-21 9:39 ` Sagi Grimberg
2016-02-22 9:01 ` Christoph Hellwig
2016-02-19 3:20 ` [PATCH v1 4/4] block: merge: " Ming Lei
2016-02-21 9:39 ` Sagi Grimberg
2016-02-22 9:01 ` Christoph Hellwig
2016-02-21 9:41 ` Sagi Grimberg [this message]
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=56C9862C.70908@dev.mellanox.co.il \
--to=sagig@dev.mellanox.co.il \
--cc=axboe@kernel.dk \
--cc=elliott@hpe.com \
--cc=hch@infradead.org \
--cc=keith.busch@intel.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.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 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.