Re: [RFC 2/2] block: add a fast path for seg split of large bio

From: Christoph Hellwig <hch@infradead.org>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Ming Lei <ming.lei@redhat.com>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC 2/2] block: add a fast path for seg split of large bio
Date: Wed, 27 Jan 2021 17:16:10 +0000	[thread overview]
Message-ID: <20210127171610.GA1733363@infradead.org> (raw)
In-Reply-To: <53b86d4e86c4913658cb0f472dcc3e22ef75396b.1609875589.git.asml.silence@gmail.com>

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.