From: Jens Axboe <[email protected]>
To: Olivier Langlois <[email protected]>
Cc: Pavel Begunkov <[email protected]>,
Hao Xu <[email protected]>,
io-uring <[email protected]>,
linux-kernel <[email protected]>
Subject: Re: [PATCH v1] io_uring: Add support for napi_busy_poll
Date: Sun, 20 Feb 2022 12:38:23 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 2/20/22 11:37 AM, Olivier Langlois wrote:
> On Sat, 2022-02-19 at 17:22 -0700, Jens Axboe wrote:
>>
>> Outside of this, I was hoping to see some performance numbers in the
>> main patch. Sounds like you have them, can you share?
>>
> Yes.
>
> It is not much. Only numbers from my application and it is far from
> being the best benchmark because the result can be influenced by
> multiple external factors.
>
> Beside addressing the race condition remaining inside io_cqring_wait()
> around napi_list for v2 patch, creating a benchmark program that
> isolate the performance of the new feature is on my todo list.
>
> I would think that creating a simple UDP ping-pong setup and measure
> RTT with and without busy_polling should be a good enough test.
Yes, a separate targeted test like that would be very useful and
interesting indeed!
> In the meantime, here are the results that I have:
>
> Without io_uring busy poll:
> reaction time to an update: 17159usec
> reaction time to an update: 19068usec
> reaction time to an update: 23055usec
> reaction time to an update: 16511usec
> reaction time to an update: 17604usec
>
> With io_uring busy poll:
> reaction time to an update: 15782usec
> reaction time to an update: 15337usec
> reaction time to an update: 15379usec
> reaction time to an update: 15275usec
> reaction time to an update: 15107usec
OK, that's a pretty good improvement in both latency and
deviation/consistency. Is this using SQPOLL, or is it using polling off
cqring_wait from the task itself? Also something to consider for the
test benchmark app, should be able to run both (which is usually just
setting the SETUP_SQPOLL flag or not, if done right).
> Concerning my latency issue with busy polling, I have found this that
> might help me:
> https://lwn.net/ml/netdev/[email protected]/
>
--
Jens Axboe
next prev parent reply other threads:[~2022-02-20 19:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-19 8:03 [PATCH v1] io_uring: Add support for napi_busy_poll Olivier Langlois
2022-02-19 21:42 ` Olivier Langlois
2022-02-20 0:22 ` Jens Axboe
2022-02-20 18:37 ` Olivier Langlois
2022-02-20 19:38 ` Jens Axboe [this message]
2022-02-21 19:29 ` Olivier Langlois
2022-02-21 5:25 ` Hao Xu
2022-02-20 20:51 ` kernel test robot
2022-02-20 21:53 ` kernel test robot
2022-02-20 21:53 ` kernel test robot
2022-02-21 5:23 ` Hao Xu
2022-02-25 5:32 ` Olivier Langlois
2022-02-25 15:32 ` Olivier Langlois
2022-02-28 18:34 ` Hao Xu
2022-02-28 21:20 ` Olivier Langlois
2022-03-01 3:53 ` Hao Xu
2022-02-28 18:26 ` Hao Xu
2022-02-28 21:01 ` Olivier Langlois
2022-03-01 8:23 ` Hao Xu
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] \
[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