From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Subject: Re: [RFC] io_uring: remove file batch-get optimisation
Date: Tue, 10 Aug 2021 18:11:52 +0100 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 8/10/21 6:04 PM, Jens Axboe wrote:
> On 8/10/21 7:52 AM, Pavel Begunkov wrote:
>> For requests with non-fixed files, instead of grabbing just one
>> reference, we get by the number of left requests, so the following
>> requests using the same file can take it without atomics.
>>
>> However, it's not all win. If there is one request in the middle
>> not using files or having a fixed file, we'll need to put back the left
>> references. Even worse if an application submits requests dealing with
>> different files, it will do a put for each new request, so doubling the
>> number of atomics needed. Also, even if not used, it's still takes some
>> cycles in the submission path.
>>
>> If a file used many times, it rather makes sense to pre-register it, if
>> not, we may fall in the described pitfall. So, this optimisation is a
>> matter of use case. Go with the simpliest code-wise way, remove it.
>
> I ran this through the peak testing, not using registered files. Doesn't
> seem to make a real difference here, at least in the quick testing.
> Which would seem to indicate we could safely kill it. But that's also
> the best case for non-registered files, would be curious to see if it
> makes a real difference now for workloads where the file is being
> shared.
Do you mean shared between cores so there is contention? Or the worst
case for non-reg with multiple files as described in the patch?
--
Pavel Begunkov
next prev parent reply other threads:[~2021-08-10 17:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-10 13:52 [RFC] io_uring: remove file batch-get optimisation Pavel Begunkov
2021-08-10 17:04 ` Jens Axboe
2021-08-10 17:11 ` Pavel Begunkov [this message]
2021-08-10 17:14 ` 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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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