Linux block layer
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Andres Freund <andres@anarazel.de>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH] io_uring: IORING_OP_TIMEOUT support
Date: Fri, 20 Sep 2019 14:18:07 -0600	[thread overview]
Message-ID: <838a193a-cb83-c6d5-f251-b113e9faf9d5@kernel.dk> (raw)
In-Reply-To: <20190920165348.pjmdnm3mozna3ous@alap3.anarazel.de>

On 9/20/19 10:53 AM, Andres Freund wrote:
> Hi,
> 
> On 2019-09-17 10:03:58 -0600, Jens Axboe wrote:
>> There's been a few requests for functionality similar to io_getevents()
>> and epoll_wait(), where the user can specify a timeout for waiting on
>> events. I deliberately did not add support for this through the system
>> call initially to avoid overloading the args, but I can see that the use
>> cases for this are valid.
> 
>> This adds support for IORING_OP_TIMEOUT. If a user wants to get woken
>> when waiting for events, simply submit one of these timeout commands
>> with your wait call. This ensures that the application sleeping on the
>> CQ ring waiting for events will get woken. The timeout command is passed
>> in a pointer to a struct timespec. Timeouts are relative.
> 
> Hm. This interface wouldn't allow to to reliably use a timeout waiting for
> io_uring_enter(..., min_complete > 1, ING_ENTER_GETEVENTS, ...)
> right?

I've got a (unpublished as of yet) version that allows you to wait for N
events, and canceling the timer it met. So that does allow you to reliably
wait for N events.

> I can easily imagine usecases where I'd want to submit a bunch of ios
> and wait for all of their completion to minimize unnecessary context
> switches, as all IOs are required to continue. But with a relatively
> small timeout, to allow switching to do other work etc.

The question is if it's worth it to add support for "wait for these N
exact events", or whether "wait for N events" is enough. The application
needs to read those completions anyway, and could then decide to loop
if it's still missing some events. Downside is that it may mean more
calls to wait, but since the io_uring is rarely shared, it might be
just fine.

Curious on your opinion.

-- 
Jens Axboe


  reply	other threads:[~2019-09-20 20:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 16:03 [PATCH] io_uring: IORING_OP_TIMEOUT support Jens Axboe
2019-09-20 16:53 ` Andres Freund
2019-09-20 20:18   ` Jens Axboe [this message]
2019-09-20 20:56     ` Andres Freund
2019-09-20 21:26       ` Jens Axboe
2019-09-20 23:10         ` Jens Axboe
2019-09-20 23:52           ` 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 \
    --in-reply-to=838a193a-cb83-c6d5-f251-b113e9faf9d5@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=andres@anarazel.de \
    --cc=linux-block@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