On Tue, Jan 05, 2021 at 07:43:38PM +0000, Pavel Begunkov wrote:
> blk_bio_segment_split() is very heavy, but the current fast path covers
> only one-segment under PAGE_SIZE bios. Add another one by estimating an
> upper bound of sectors a bio can contain.
>
> One restricting factor here is queue_max_segment_size(), which it
> compare against full iter size to not dig into bvecs. By default it's
> 64KB, and so for requests under 64KB, but for those falling under the
> conditions it's much faster.
I think this works, but it is a pretty gross heuristic, which also
doesn't help us with NVMe, which is the I/O fast path of choice for
most people. What is your use/test case?
> + /*
> + * Segments are contiguous, so only their ends may be not full.
> + * An upper bound for them would to assume that each takes 1B
> + * but adds a sector, and all left are just full sectors.
> + * Note: it's ok to round size down because all not full
> + * sectors are accounted by the first term.
> + */
> + max_sectors = bio_segs * 2;
> + max_sectors += bio->bi_iter.bi_size >> 9;
> +
> + if (max_sectors < q_max_sectors) {
I don't think we need the max_sectors variable here.
