2 ms·

The means may be different, but the ends they aim for seem to be similar. The ends here are improved latency, throughput, parallelism, non-blocking APIs and sec

The means may be different, but the ends they aim for seem to be similar. The ends here are improved latency, throughput, parallelism, non-blocking APIs and security. The above-mentioned improvements aim to address the first four without completely bypassing the kernel, instead changing APIs so they step out of the way most of the time, limiting them to coordination tasks and then either offloading to the hardware or directly piping the data to/from userspace mappings without additional context switches where needed. VMs using SR-IOV address the security aspect. It's basically the difference between a green field design and tacking all those innovations onto the glueball that is linux. The latter may be ugly and complex, but it has the advantage of being backwards-compatible.

loeg 8y ago
> It's basically the difference between a green field design and tacking all those innovations onto the glueball that is linux. The latter may be ugly and complex, but it has the advantage of being backwards-compatible. I'm definitely not trying to argue in favor of the paper's opinion. :-) I just believe the author of the article would disagree that the glueball your earlier remarks describe addresses the author's concerns. They specifically say that Linux cannot be fixed to their satisfaction, or at least argue that idea. Look for the section on page 5 headed, "Why not use kernel-bypass techniques on Linux?"
- the8472 8y ago
  Well, and all I am saying is that the paper, including the section you mention, don't take these latest developments into account. They're not kernel bypasses. They're driver level optimizations and traditional APIs operating on file descriptors and virtual memory aiming to solve similar problems. This stuff is very new of course, so we have to wait for something to actually integrate all those pieces and then for benchmarks.

loeg 8y ago

> It's basically the difference between a green field design and tacking all those innovations onto the glueball that is linux. The latter may be ugly and complex, but it has the advantage of being backwards-compatible. I'm definitely not trying to argue in favor of the paper's opinion. :-) I just believe the author of the article would disagree that the glueball your earlier remarks describe addresses the author's concerns. They specifically say that Linux cannot be fixed to their satisfaction, or at least argue that idea. Look for the section on page 5 headed, "Why not use kernel-bypass techniques on Linux?"

the8472 8y ago
Well, and all I am saying is that the paper, including the section you mention, don't take these latest developments into account. They're not kernel bypasses. They're driver level optimizations and traditional APIs operating on file descriptors and virtual memory aiming to solve similar problems. This stuff is very new of course, so we have to wait for something to actually integrate all those pieces and then for benchmarks.