From: Pavel Begunkov <asml.silence@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, Nitesh Shetty <nitheshshetty@gmail.com>
Cc: Nitesh Shetty <nj.shetty@samsung.com>,
gost.dev@samsung.com, io-uring@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] io_uring/rsrc: send exact nr_segs for fixed buffer
Date: Wed, 16 Apr 2025 22:03:09 +0100 [thread overview]
Message-ID: <951a5f20-2ec4-40c3-8014-69cd6f4b9f0f@gmail.com> (raw)
In-Reply-To: <a263d544-f153-4918-acea-5ce9db6d0d60@kernel.dk>
On 4/16/25 21:30, Jens Axboe wrote:
> On 4/16/25 2:29 PM, Pavel Begunkov wrote:
>> On 4/16/25 21:01, Jens Axboe wrote:
>>> On 4/16/25 1:57 PM, Nitesh Shetty wrote:
>> ...
>>>>> /*
>>>>> @@ -1073,7 +1075,6 @@ static int io_import_fixed(int ddir, struct iov_iter *iter,
>>>>> * since we can just skip the first segment, which may not
>>>>> * be folio_size aligned.
>>>>> */
>>>>> - const struct bio_vec *bvec = imu->bvec;
>>>>>
>>>>> /*
>>>>> * Kernel buffer bvecs, on the other hand, don't necessarily
>>>>> @@ -1099,6 +1100,27 @@ static int io_import_fixed(int ddir, struct iov_iter *iter,
>>>>> }
>>>>> }
>>>>>
>>>>> + /*
>>>>> + * Offset trimmed front segments too, if any, now trim the tail.
>>>>> + * For is_kbuf we'll iterate them as they may be different sizes,
>>>>> + * otherwise we can just do straight up math.
>>>>> + */
>>>>> + if (len + offset < imu->len) {
>>>>> + bvec = iter->bvec;
>>>>> + if (imu->is_kbuf) {
>>>>> + while (len > bvec->bv_len) {
>>>>> + len -= bvec->bv_len;
>>>>> + bvec++;
>>>>> + }
>>>>> + iter->nr_segs = bvec - iter->bvec;
>>>>> + } else {
>>>>> + size_t vec_len;
>>>>> +
>>>>> + vec_len = bvec->bv_offset + iter->iov_offset +
>>>>> + iter->count + ((1UL << folio_shift) - 1);
>>>>> + iter->nr_segs = vec_len >> folio_shift;
>>>>> + }
>>>>> + }
>>>>> return 0;
>>>>> }
>>>> This might not be needed for is_kbuf , as they already update nr_seg
>>>> inside iov_iter_advance.
>>>
>>> How so? If 'offset' is true, then yes it'd skip the front, but it
>>> doesn't skip the end part. And if 'offset' is 0, then no advancing is
>>> done in the first place - which does make sense, as it's just advancing
>>> from the front.
>>>
>>>> How about changing something like this ?
>>>
>>> You can't hide this in the if (offset) section...
>>
>> Should we just make it saner first? Sth like these 3 completely
>> untested commits
>>
>> https://github.com/isilence/linux/commits/rsrc-import-cleanup/
>>
>> And then it'll become
>>
>> nr_segs = ALIGN(offset + len, 1UL << folio_shift);
>
> Let's please do that, certainly an improvement. Care to send this out? I
> can toss them at the testing. And we'd still need that last patch to
I need to test it first, perhaps tomorrow
> ensure the segment count is correct. Honestly somewhat surprised that
Right, I can pick up the Nitesh's patch to that.
> the only odd fallout of that is (needlessly) hitting the bio split path.
It's perfectly correct from the iter standpoint, AFAIK, length
and nr of segments don't have to match. Though I am surprised
it causes perf issues in the split path.
Btw, where exactly does it stumble in there? I'd assume we don't
need to do the segment correction for kbuf as the bio splitting
can do it (and probably does) in exactly the same way?
--
Pavel Begunkov
next prev parent reply other threads:[~2025-04-16 21:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250416055250epcas5p25fa8223a1bfeea5583ad8ba88c881a05@epcas5p2.samsung.com>
2025-04-16 5:44 ` [PATCH] io_uring/rsrc: send exact nr_segs for fixed buffer Nitesh Shetty
2025-04-16 14:19 ` Jens Axboe
2025-04-16 14:43 ` Jens Axboe
2025-04-16 14:49 ` Jens Axboe
2025-04-16 15:03 ` Pavel Begunkov
2025-04-16 15:07 ` Jens Axboe
2025-04-16 18:25 ` Jens Axboe
2025-04-16 19:57 ` Nitesh Shetty
2025-04-16 20:01 ` Jens Axboe
2025-04-16 20:29 ` Pavel Begunkov
2025-04-16 20:30 ` Jens Axboe
2025-04-16 21:03 ` Pavel Begunkov [this message]
2025-04-16 22:23 ` Jens Axboe
2025-04-16 22:42 ` Jens Axboe
2025-04-17 9:12 ` Pavel Begunkov
2025-04-16 20:03 ` Keith Busch
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=951a5f20-2ec4-40c3-8014-69cd6f4b9f0f@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=gost.dev@samsung.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nitheshshetty@gmail.com \
--cc=nj.shetty@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox