linux-toradex.git/block/blk-merge.c, branch v4.1.30

Fix bug in blk_rq_merge_ok

2015-03-20T14:50:41+00:00

Use the right array index to reference the last
element of rq->biotail->bi_io_vec[]

Signed-off-by: Wenbo Wang 
Reviewed-by: Chong Yuan 
Fixes: 66cb45aa41315 ("block: add support for limiting gaps in SG lists")
Cc: stable@kernel.org
Signed-off-by: Jens Axboe

block: remove unused function blk_bio_map_sg

2015-02-11T18:24:14+00:00

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

block: prevent request-to-request merging with gaps if not allowed

2015-02-11T16:23:52+00:00

If the queue has SG_GAPS set, we must not merge across an sg gap.
This is caught for the bio case, but currently not for the
more rare case of merging two requests directly.

Signed-off-by: Keith Busch 

Cut the dm bits, those will go through the dm tree, and fixed
the test_bit() test.

Signed-off-by: Jens Axboe

block: blk-merge: fix blk_recount_segments()

2014-11-11T23:24:15+00:00

For cloned bio, bio->bi_vcnt can't be used at all, and we
have resort to bio_segments() to figure out how many
segment there are in the bio.

Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe

blk-merge: recaculate segment if it isn't less than max segments

2014-10-22T01:00:32+00:00

The problem is introduced by commit 764f612c6c3c231b(blk-merge:
don't compute bi_phys_segments from bi_vcnt for cloned bio),
and merge is needed if number of current segment isn't less than
max segments.

Strictly speaking, bio->bi_vcnt shouldn't be used here since
it may not be accurate in cases of both cloned bio or bio cloned
from, but bio_segments() is a bit expensive, and bi_vcnt is still
the biggest number, so the approach should work.

Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe

blk-merge: don't compute bi_phys_segments from bi_vcnt for cloned bio

2014-10-09T19:11:44+00:00

It isn't correct to figure out req->bi_phys_segments from bio->bi_vcnt
if the bio is cloned.

Signed-off-by: Ming Lei 
Tested-by: Jeff Mahoney 
Signed-off-by: Jens Axboe

block: Don't merge requests if integrity flags differ

2014-09-27T15:14:57+00:00

We'd occasionally merge requests with conflicting integrity flags.
Introduce a merge helper which checks that the requests have compatible
integrity payloads.

Signed-off-by: Martin K. Petersen 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Jens Axboe

blk-merge: fix blk_recount_segments

2014-09-02T16:25:12+00:00

QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
so bio->bi_phys_segment computed may be bigger than
queue_max_segments(q) for blk-mq devices, then drivers will
fail to handle the case, for example, BUG_ON() in
virtio_queue_rq() can be triggerd for virtio-blk:

	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359146

This patch fixes the issue by ignoring the QUEUE_FLAG_NO_SG_MERGE
flag if the computed bio->bi_phys_segment is bigger than
queue_max_segments(q), and the regression is caused by commit
05f1dd53152173(block: add queue flag for disabling SG merging).

Reported-by: Kick In 
Tested-by: Chris J Arges 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe

block: add support for limiting gaps in SG lists

2014-06-24T22:22:24+00:00

Another restriction inherited for NVMe - those devices don't support
SG lists that have "gaps" in them. Gaps refers to cases where the
previous SG entry doesn't end on a page boundary. For NVMe, all SG
entries must start at offset 0 (except the first) and end on a page
boundary (except the last).

Signed-off-by: Jens Axboe

block: add queue flag for disabling SG merging

2014-05-29T15:53:32+00:00

If devices are not SG starved, we waste a lot of time potentially
collapsing SG segments. Enough that 1.5% of the CPU time goes
to this, at only 400K IOPS. Add a queue flag, QUEUE_FLAG_NO_SG_MERGE,
which just returns the number of vectors in a bio instead of looping
over all segments and checking for collapsible ones.

Add a BLK_MQ_F_SG_MERGE flag so that drivers can opt-in on the sg
merging, if they so desire.

Signed-off-by: Jens Axboe