From: Pavel Begunkov <asml.silence@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Ming Lei <ming.lei@redhat.com>
Subject: Re: [PATCH 2/2] bio: optimise bvec iteration
Date: Wed, 2 Dec 2020 13:50:19 +0000 [thread overview]
Message-ID: <521781a4-fb18-e9bd-76ae-8cd3a46680ec@gmail.com> (raw)
In-Reply-To: <fac832fe-45a2-5630-55a2-3684e434f998@gmail.com>
On 26/11/2020 12:32, Pavel Begunkov wrote:
> On 26/11/2020 10:02, Christoph Hellwig wrote:
>> On Tue, Nov 24, 2020 at 05:58:13PM +0000, Pavel Begunkov wrote:
>>> __bio_for_each_bvec(), __bio_for_each_segment() and bio_copy_data_iter()
>>> fall under conditions of bvec_iter_advance_single(), which is a faster
>>> and slimmer version of bvec_iter_advance(). Add
>>> bio_advance_iter_single() and convert them.
>>
>> Are you sure about bio_advance_iter()? That API looks like it might
>
> Both those listed bio_for_each*() pass bvl.bv_len, which is truncated to
> current segment by bio_iter_iovec() (i.e. bvec_iter_bvec) or
> mp_bvec_iter_bvec().
>
> And just to note that I didn't change bio_advance_iter() but added a
> new function.
> There is always space for stupid mistakes, but I'm sure. What makes you
> to think opposite? I may have missed it.
Christoph, any doubts left?
>> not always be limited to a single segment, and might at least need a
>> WARN_ON_ONCE to make sure it is not abused.
>
> I thought twice about converting other places as you commented before,
> and it looks saner to not do that exactly for that reason. I prefer
> to leave *_single() versions for rare but high impact cases like
> for_each()s.
> And as it's contained I decided to not add overhead on WARN_ONCE(),
> e.g. with inlining and w/o string dedup it grows .data section much.
>
--
Pavel Begunkov
next prev parent reply other threads:[~2020-12-02 13:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 17:58 [PATCH 0/2] optimise bvec/bio iteration Pavel Begunkov
2020-11-24 17:58 ` [PATCH 1/2] block: optimise for_each_bvec() advance Pavel Begunkov
2020-11-26 10:00 ` Christoph Hellwig
2020-11-24 17:58 ` [PATCH 2/2] bio: optimise bvec iteration Pavel Begunkov
2020-11-26 10:02 ` Christoph Hellwig
2020-11-26 12:32 ` Pavel Begunkov
2020-12-02 13:50 ` Pavel Begunkov [this message]
2020-12-02 14:56 ` Christoph Hellwig
2020-12-02 16:47 ` [PATCH 0/2] optimise bvec/bio iteration Jens Axboe
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=521781a4-fb18-e9bd-76ae-8cd3a46680ec@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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.