From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH for-4.4] block: split bios to max possible length
Date: Tue, 5 Jan 2016 15:09:38 +0000 [thread overview]
Message-ID: <20160105150938.GA20832@localhost.localdomain> (raw)
In-Reply-To: <CACVXFVPOYra24SNmGBthcheYv_kY=5Fv-6s=-bSwwZijudXapw@mail.gmail.com>
On Tue, Jan 05, 2016@12:54:53PM +0800, Ming Lei wrote:
> On Tue, Jan 5, 2016@2:24 AM, Keith Busch <keith.busch@intel.com> wrote:
> > This allows bio splits in the middle of a vector to form the largest
>
> Wrt. the current block stack, one segment always hold one or more bvec,
> instead of part of bvec, so better to be careful about this handling.
Hi Ming,
Could you help me understand your concern here? If we split a vector
somewhere in the middle, it becomes two different bvecs. The first is
the last segment in the first bio, the second is the first segment in
the split bio, right?
It's not necessarily a new segment if it is physically contiguous with
the previous (if it exists at all), but duplicating the logic to coalesce
addresses doesn't seem to be worth that optimization.
> > possible bio at the h/w's desired alignment, and guarantees the bio being
> > split will have some data. Previously, if the first vector's length was
> > greater than the allowable amount, the bio would split at a zero length
> > and hit a kernel BUG.
>
> That is introduced by d3805611130a, and zero length can't be splitted
> previously because queue_max_sectors() is at least one PAGE_SIZE.
Can a bvec's length exceed a PAGE_SIZE? They point to pages, so I
suppose not.
But it should be more efficient to split to the largest allowed by the
hardware. We can contrive a scenario where a bio would be split many
times more than necessary without this patch. Let's say queue_max_sectors
is a PAGE_SIZE, and we want to submit '2 * PAGE_SIZE' worth of data
addressed in 3 bvecs. Previously that would split three times; now it
will split only twice.
next prev parent reply other threads:[~2016-01-05 15:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-04 18:24 [PATCH for-4.4] block: split bios to max possible length Keith Busch
2016-01-05 4:54 ` Ming Lei
2016-01-05 15:09 ` Keith Busch [this message]
2016-01-06 2:17 ` Ming Lei
2016-01-06 5:51 ` Keith Busch
2016-01-06 6:29 ` Ming Lei
2016-01-06 6:53 ` Ming Lei
2016-01-06 15:18 ` Keith Busch
2016-01-06 15:43 ` Ming Lei
2016-01-06 16:21 ` Keith Busch
2016-01-07 0:14 ` Ming Lei
2016-01-07 10:46 ` Kent Overstreet
2016-01-09 11:10 ` Ming Lei
2016-01-06 15:29 ` Keith Busch
2016-01-06 9:46 ` 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=20160105150938.GA20832@localhost.localdomain \
--to=keith.busch@intel.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.