8 ms·

How does it make Linux compare to Windows, OSX and *BSD?

• Arnavion 6y ago
  The underlying principle of submitting a job to be done and letting the kernel do it (submitting a read() and waiting for it to complete), as opposed to the original model of waiting for the kernel when it's ready to let you do the job (waiting for an fd to become readable so you can call read() on it) is the same as the completion-based model of Windows async I/O (and I think BSD's kqueue too?) as opposed to the readiness-based model of epoll. The part of where this submission and completion information involves a ring buffer mapped to kernel space is unique to Linux, I believe.
  • Const-me 6y ago
    > The part of where this submission and completion information involves a ring buffer mapped to kernel space is unique to Linux RIO is very similar and predates Linux version by many years: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh997032(v=ws.11) https://docs.microsoft.com/en-us/previous-versions/windows/i... Main downside, that thing is only for sockets.
    • muststopmyths 6y ago
      And plain old overlapped I/O can lock pages in memory. With Direct I/O devices can directly DMA into these buffers, so theoretically any device can provide similar functionality and use completion ports for notification. (or polling, since the possible high "interrupt rate" bottleneck of completion notifications is one of the things that motivated RIO)
      • Const-me 6y ago
        Mapping pages is relatively expensive. Not the mapping itself, but as a consequence of such update CPU has to flush at least a portion of TLB cache. With overlapped I/O the kernel has to do that for every I/O request. With RIO and now io_uring, kernels map buffers to both kernel and user addresses spaces just once on initial setup, and reuse the same buffer for many I/O operations.
        • muststopmyths 6y ago
          You're right, I forgot about the cost of locking pages for every overlapped I/O.