Re: [PATCH v1 1/1] [io_uring] require RWF_HIPRI for iopoll reads and writes

["Stefan Bühler" <source@stbuehler.de>]

Hi,

On 01.05.19 14:43, Jens Axboe wrote:
> On 5/1/19 5:52 AM, Stefan Bühler wrote:
>> This makes the mapping RWF_HIPRI <-> IOCB_HIPRI <-> iopoll more
>> consistent; it also allows supporting iopoll operations without
>> IORING_SETUP_IOPOLL in the future.
> 
> I don't want to make this change now. Additionally, it's never
> going to be possible to support polled IO mixed with non-polled
> IO on an io_uring instance, as that makes the wait part of IO
> impossible to support without adding tracking of requests.
> 
> As we can never mix them, it doesn't make a lot of sense to
> request RWF_HIPRI for polled IO.

I'm not just new to memory ordering, I'm also new to kernel internals :)

To me it looks like iopoll is basically a busy-loop interface; it helps
making things move forward more quickly, while they still might (or
might not) finish on their own.

And io_do_iopoll simply loops over all requests and runs a single
iteration for them, or, if there is only one request
("!poll_multi_file"), it tells it to spin internally.

While there are multiple requests it can't spin in a single request
anyway, and I don't see why it couldn't also check for completion of
non-polled requests after looping over the polled requests (whether by
only checking the CQ tail or actively tracking (why would that be bad?)
the requests some other way).  This only means that as long there are
non-polled requests pending it mustn't spin in a single request.

And if there are no polled-requests at all it could use io_cqring_wait.

So I don't see why it would be impossible to mix polled and non-polled
IO requests.

Any hints what I'm missing here?

(Even if it turns out to be impossible I still think requiring RWF_HIPRI
would be the right way, but well...)

cheers,
Stefan