3 ms·

I'm wondering what has fundamentally changed in computing between the creation of kqueue and io_uring so the latter is able to better fit modern reality.

vacuity 2y ago
I don't know that there were relevant changes between the advent of each, so much as kqueue just didn't have existing features in mind. I assume GP is referring to the ring buffer design and/or completion-based processing, as part of the ability to batch syscall processing. This is reminiscent of external work like FlexSC and can be viewed as mechanical sympathy.
deleted 2y ago
[deleted]
mananaysiempre 2y ago
I don’t know which things here are actually relevant to the differences between the two, but of course there have been changes. Core counts are much higher. You can stripe some enterprise SSDs and get bandwidth within an order of magnitude or so of your RAM. Yet clocks aren’t that much higher, and user-supervisor transitions are comparatively much more expensive. There’s a reason Lemire’s talk on simdjson is called “Data engineering at the speed of your disk”.
adrian_b 2y ago
I have not looked at the io_uring implementation to see if it really has improvements from this point of view, but something that has changed during the quarter of century from the design of kqueue until now is that currently it has become much more important than before to minimize the number of context switches caused by system calls in the programs that desire to reach a high performance for input/output. The reason is that with faster CPU cores, more cores sharing the memory, bigger CPU core states and relatively slower memory in comparison with the CPU cores, the time wasted by a context switch has become relatively greater in comparison with the time used by a CPU core to do useful work. So hopefully, implementing some I/O task using io_uring should require less system calls than when using kqueue or epoll. According to the io_uring man page, this should be true.
- oasisaimlessly 2y ago
  In addition to the reasons you listed, context switches have also been significantly slowed down by Meltdown/Spectre speculative execution vulnerability mitigations.

vacuity 2y ago

I don't know that there were relevant changes between the advent of each, so much as kqueue just didn't have existing features in mind. I assume GP is referring to the ring buffer design and/or completion-based processing, as part of the ability to batch syscall processing. This is reminiscent of external work like FlexSC and can be viewed as mechanical sympathy.

deleted 2y ago

[deleted]

mananaysiempre 2y ago

I don’t know which things here are actually relevant to the differences between the two, but of course there have been changes. Core counts are much higher. You can stripe some enterprise SSDs and get bandwidth within an order of magnitude or so of your RAM. Yet clocks aren’t that much higher, and user-supervisor transitions are comparatively much more expensive. There’s a reason Lemire’s talk on simdjson is called “Data engineering at the speed of your disk”.

adrian_b 2y ago

I have not looked at the io_uring implementation to see if it really has improvements from this point of view, but something that has changed during the quarter of century from the design of kqueue until now is that currently it has become much more important than before to minimize the number of context switches caused by system calls in the programs that desire to reach a high performance for input/output. The reason is that with faster CPU cores, more cores sharing the memory, bigger CPU core states and relatively slower memory in comparison with the CPU cores, the time wasted by a context switch has become relatively greater in comparison with the time used by a CPU core to do useful work. So hopefully, implementing some I/O task using io_uring should require less system calls than when using kqueue or epoll. According to the io_uring man page, this should be true.

oasisaimlessly 2y ago
In addition to the reasons you listed, context switches have also been significantly slowed down by Meltdown/Spectre speculative execution vulnerability mitigations.