[Bug 58704] New: io_uring support for Wine

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58704

Bug ID: 58704
           Summary: io_uring support for Wine
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

This issue mostly relates to the server(for filesystem operations), it seems
like the networking implementation could be done outside the server.

Just throwing this out there, it's highly unlikely I will work on it for
various reasons.

Wine still doesn't have io_uring support though, quite a few projects have
already implemented io_uring support. Wine would also do with any performance
benefits. io_uring is at least promoted as performance oriented, this makes it
very interesting.

io_uring offers performance benefits in multiple fronts.

-> The first and probably the simplest is where operations on file might not
have to make calls to 'fget'; typically when an operation is executed on files
in Linux, it will involve some call to 'fget' one way or the other. With
io_uring, it's possible to register files so that this 'fget' call is avoided.
I am not sure how much performance benefit that could achieve. But, still an
optimization nonetheless. Similarly, you could register buffers for
opcodes(which translate to syscalls) so they're validated, mapped and so on so
forth beforehand. When the actual operations/syscall are being executed, this
boilerplate is not called. That is also an optimization.

-> io_uring allows submitting a batch of syscalls(opcode operations) via one
single syscall. This is an optimization, because, of course, without io_uring,
you'd have to make multiple syscalls to achieve the same. However, it only
seems like this optimization would only be applicable when making very many
syscalls and making them very fast otherwise when making singular syscalls,
they have to wait until the batch is full and hence would introduce some
latency in low throughput situations.

-> There might be other optimizations that I have not considered. What
interests me most, though, is the syscall/request polling feature which allows
applications to submit syscalls(opcode) via zero syscalls. io_uring sets up a
kernel thread which polls the io ring and hence when submissions are made, the
thread will discover them without any syscalls been made. This is very
interesting and would be a straightforward mega-optimization were it not for
that fact that the created kernel thread does pin a CPU. Would this work well
with other work that's competing for CPU? It's consequently not very clear
whether this would be an improvement to Wine, which makes syscalls alongside
and in the midst of doing other heavy work.

Any thoughts?

[Bug 58704] io_uring support for Wine

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58704

David Kahurani  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 58704] io_uring support for Wine

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=58704

Zeb Figura  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Zeb Figura  ---
I don't think Wine is going to get anything out of io_uring.

There's not anything in the way of batching we do; for anything interesting one
win32 syscall is going to translate to one POSIX syscall.

Nor do we do anything interesting that's asynchronous. Win32 I/O is of course
asynchronous by nature, but in a way that requires manual handling; we can't
easily implement async win32 I/O on top of async Linux I/O.

And even we could, there's two kinds of I/O we do: regular file I/O, which can
often skip a server call but is by nature synchronous, and non-regular file
I/O, which is asynchronous but also needs to go through the server to signal
completion (and sometimes other things). The server RPC is going to dwarf
whatever time io_uring might theoretically save.

If I/O is a bottleneck—and I haven't yet seen an application where it actually
*is*—then we'll need to address it in other ways.