linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olivier Langlois <olivier@trillion01.com>
To: Pavel Begunkov <asml.silence@gmail.com>,
	Jens Axboe <axboe@kernel.dk>,
	io-uring@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] io_uring: reduce latency by reissueing the operation
Date: Thu, 10 Jun 2021 13:56:53 -0400	[thread overview]
Message-ID: <9938f22a0bb09f344fa5c9c5c1b91f0d12e7566f.camel@trillion01.com> (raw)
In-Reply-To: <a7d6f2fd-b59e-e6fa-475a-23962d45b6fa@gmail.com>

On Thu, 2021-06-10 at 16:51 +0100, Pavel Begunkov wrote:
> Right, but it still stalls other requests and IIRC there are people
> not liking the syscall already taking too long. Consider
> io_req_task_queue(), adds more overhead but will delay execution
> to the syscall exit.
> 
> In any case, would be great to have numbers, e.g. to see if
> io_req_task_queue() is good enough, how often your problem
> takes places and how much it gives us.
> 
I will get you more more data later but I did run a fast test that
lasted 81 seconds with a single TCP connection.

The # of times that the sqe got reissued is 57.

I'll intrumentalize a bit the code to answer the following questions:

1. What is the ratio of reissued read sqe/total read sqe
2. Average exec time of __io_queue_sqe() for a read sqe when data is
already available vs avg exec time when sqe is reissued
3. average exec time when the sqe is pushed to async when it could have
been reissued.

With that info, I think that we will be in better position to evaluate
whether or not the patch is good or not.

Can you think of other numbers that would be useful to know to evaluate
the patch performance?



  reply	other threads:[~2021-06-10 17:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <60c13bec.1c69fb81.73967.f06dSMTPIN_ADDED_MISSING@mx.google.com>
2021-06-10  9:03 ` [PATCH] io_uring: reduce latency by reissueing the operation Pavel Begunkov
     [not found]   ` <4b5644bff43e072a98a19d7a5ca36bb5e11497ec.camel@trillion01.com>
2021-06-10 15:51     ` Pavel Begunkov
2021-06-10 17:56       ` Olivier Langlois [this message]
2021-06-10 19:32         ` Pavel Begunkov
2021-06-11  3:55           ` Olivier Langlois
2021-06-17 18:10             ` Pavel Begunkov
2021-06-18 22:45               ` Olivier Langlois
2021-06-20 20:55                 ` Pavel Begunkov
2021-06-20 21:31                   ` Olivier Langlois
2021-06-20 22:04                     ` Pavel Begunkov
     [not found] <60c13bec.1c69fb81.f2c1e.6444SMTPIN_ADDED_MISSING@mx.google.com>
2021-06-16 12:48 ` Jens Axboe
2021-06-18 21:38   ` Olivier Langlois

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=9938f22a0bb09f344fa5c9c5c1b91f0d12e7566f.camel@trillion01.com \
    --to=olivier@trillion01.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).