News for hackers. Stuff that matters.
Re:Linux: IO without entering the kernel by reacharavindh on Sunday December 16, 2018 @07:36AM (#18692831)
I don't know if it is the case, but, I would happily trade off two cores to get better IO in most cases in our nodes servicing IO bound jobs. Otherwise, those CPU cores are just idling anyway because of IO..

With the current growth of CPU leaning towards more and more cores with ever smaller improvements in single core performance, dedicating spare cores for such perm improvements is not at all a bad idea.

Re:Linux: IO without entering the kernel by kbwt on Sunday December 16, 2018 @08:03AM (#18692888)
The only thing this really improves is latency, because you can always batch more I/O into a single syscall.
Re:Linux: IO without entering the kernel by beagle3 on Sunday December 16, 2018 @09:26AM (#18693148)
You can batch 1000 writes to the same socket into a single syscall, but you can’t batch writing to 1000 different sockets into one syscall. (And it is actually a common occurrence to write the same message to 100 sockets at the same time - e.g. in an IRC server with 100 people in A room)
Re:Linux: IO without entering the kernel by kbwt on Sunday December 16, 2018 @10:11AM (#18693358)
There's io_submit which lets you batch IOs on any number of fds. It appears to lack socket support, but I don't see any reason why that couldn't be added.
Re:Linux: IO without entering the kernel by jandrewrogers on Sunday December 16, 2018 @02:25PM (#18694671)
There is a fundamental difference between disk I/O and network I/O that cause them to be treated differently.

For disk I/O, you have absolute control over the number and type of events that may be pending, allowing you to strictly bound resource consumption and defer handling of those events indefinitely with no consequences. Similarly, you can opportunistically use unused disk I/O capacity to bring future I/O events forward with little cost e.g. pre-fetching. The worst case scenario you have to deal with in terms of disk I/O is self-inflicted, which makes for relatively simple engineering.

Network I/O events, by contrast, are exogenous and unpredictable. You often have little control over the timing or the quantity of these events, and the only limit on potential resource consumption is the bandwidth of your network hardware. Not only do you have to handle the worst case scenario in these cases, you also have little control over what a worst case scenario can look like. This leads to very different design decisions and interactions with the I/O subsystem versus disk.

Re:Linux: IO without entering the kernel by gpderetta on Sunday December 16, 2018 @11:13AM (#18693656)
Io_submit is part of the Linux aio subsystem. Thus patch is literally a extension to that subsystem to avoid doing a kernel call to submit aio requests and collect results.
Re:Linux: IO without entering the kernel by kbwt on Sunday December 16, 2018 @11:26AM (#18693708)
Sure, but this patch is only useful for single-purpose, HFT-like workloads. Batched io_submit on sockets would be useful for any application sending many small packets to lots of clients, such as game servers.
Re:Linux: IO without entering the kernel by gpderetta on Sunday December 16, 2018 @01:03PM (#18694189)
For network io, an userspace accelerated network stack is probably better though.