public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: David Wei <[email protected]>, [email protected]
Subject: Re: [PATCH 4/5] io_uring: add support for batch wait timeout
Date: Tue, 20 Aug 2024 15:31:09 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 8/20/24 3:10 PM, David Wei wrote:
> On 2024-08-19 16:28, Jens Axboe wrote:
>> Waiting for events with io_uring has two knobs that can be set:
>>
>> 1) The number of events to wake for
>> 2) The timeout associated with the event
>>
>> Waiting will abort when either of those conditions are met, as expected.
>>
>> This adds support for a third event, which is associated with the number
>> of events to wait for. Applications generally like to handle batches of
>> completions, and right now they'd set a number of events to wait for and
>> the timeout for that. If no events have been received but the timeout
>> triggers, control is returned to the application and it can wait again.
>> However, if the application doesn't have anything to do until events are
>> reaped, then it's possible to make this waiting more efficient.
>>
>> For example, the application may have a latency time of 50 usecs and
>> wanting to handle a batch of 8 requests at the time. If it uses 50 usecs
>> as the timeout, then it'll be doing 20K context switches per second even
>> if nothing is happening.
>>
>> This introduces the notion of min batch wait time. If the min batch wait
>> time expires, then we'll return to userspace if we have any events at all.
>> If none are available, the general wait time is applied. Any request
>> arriving after the min batch wait time will cause waiting to stop and
>> return control to the application.
> 
> I think the batch request count should be applied to the min_timeout,
> such that:
> 
> start_time          min_timeout            timeout
>     |--------------------|--------------------|
> 
> Return to user between [start_time, min_timeout) if there are wait_nr
> number of completions, checked by io_req_local_work_add(), or is it
> io_wake_function()?

Right, if we get the batch fulfilled, we should ALWAYS return.

If we have any events and min_timeout expires, return.

If not, sleep the full timeout.

> Return to user between [min_timeout, timeout) if there are at least one
> completion.

Yes

> Return to user at timeout always.

Yes

This should be how it works, and how I described it in the commit
message.

-- 
Jens Axboe


  reply	other threads:[~2024-08-20 21:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19 23:28 [PATCHSET v4 0/5] Add support for batched min timeout Jens Axboe
2024-08-19 23:28 ` [PATCH 1/5] io_uring: encapsulate extraneous wait flags into a separate struct Jens Axboe
2024-08-19 23:28 ` [PATCH 2/5] io_uring: move schedule wait logic into helper Jens Axboe
2024-08-19 23:28 ` [PATCH 3/5] io_uring: implement our own schedule timeout handling Jens Axboe
2024-08-20 20:08   ` David Wei
2024-08-20 21:34     ` Jens Axboe
2024-08-20 21:37       ` David Wei
2024-08-20 21:39         ` Jens Axboe
2024-08-20 22:04           ` Pavel Begunkov
2024-08-20 22:06           ` David Wei
2024-08-20 22:13             ` Pavel Begunkov
2024-08-20 22:14               ` David Wei
2024-08-20 22:19                 ` Jens Axboe
2024-08-20 22:51                   ` Jens Axboe
2024-08-20 22:54                     ` Jens Axboe
2024-08-19 23:28 ` [PATCH 4/5] io_uring: add support for batch wait timeout Jens Axboe
2024-08-20 21:10   ` David Wei
2024-08-20 21:31     ` Jens Axboe [this message]
2024-08-20 21:59       ` David Wei
2024-08-20 21:36     ` Jens Axboe
2024-08-20 22:08       ` Pavel Begunkov
2024-08-20 22:46   ` Pavel Begunkov
2024-08-20 22:47     ` Pavel Begunkov
2024-08-20 22:58       ` Jens Axboe
2024-08-21  0:08         ` Pavel Begunkov
2024-08-21 14:22           ` Jens Axboe
2024-08-19 23:28 ` [PATCH 5/5] io_uring: wire up min batch wake timeout Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2024-08-21 14:16 [PATCHSET v5 0/5] Add support for batched min timeout Jens Axboe
2024-08-21 14:16 ` [PATCH 4/5] io_uring: add support for batch wait timeout Jens Axboe
2024-08-21 18:25   ` David Wei
2024-08-21 18:38     ` Jens Axboe
2024-08-21 18:54       ` David Wei
2024-08-22 13:46   ` Pavel Begunkov
2024-08-22 15:37     ` Jens Axboe
2024-08-22 16:06       ` Pavel Begunkov
2024-08-22 16:14         ` Jens Axboe
2024-08-22 16:24           ` Pavel Begunkov
2024-08-16 20:38 [PATCHSET v3 0/5] Add support for batched min timeout Jens Axboe
2024-08-16 20:38 ` [PATCH 4/5] io_uring: add support for batch wait timeout 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