Re: [RFC 2/2] block: add a fast path for seg split of large bio
From: Christoph Hellwig <hch@infradead.org>
Date: 2021-01-27 17:18:33
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?
quoted hunk ↗ jump to hunk
+ /* + * 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.