Linux: IO without entering the kernel

Re:Linux: IO without entering the kernel by geofft on Sunday December 16, 2018 @07:13AM (#18692772)

The motivating benefit is performance, but a side one the author mentioned on Twitter https://twitter.com/axboe/status/1073320502532263936 is sidestepping Meltdown and similar vulnerabilities from having the kernel and the OS in the same address space (even though they're separated by a privilege boundary). In a scheme like this, you can theoretically dedicate one core to the application and a separate one to the kernel, and minimize speculation, cache sharing, etc. between the two. The application and the kernel share a portion of memory, so the kernel doesn't ever run on the application's CPU.

This is questionably practical for a general-purpose machine, but for a server system used entirely as a hypervisor, or web server, or file aerver, or something, it might fit really well.

[ Parent | on HN ]

Re:Linux: IO without entering the kernel by cyphar on Sunday December 16, 2018 @07:20AM (#18692793)

But wouldn't having the kernel pinned to a different core hurt performance due to NUMA, or through having to do lots of cross-calls?

[ Parent | on HN ]

Re:Linux: IO without entering the kernel by geofft on Sunday December 16, 2018 @07:30AM (#18692814)

Depends on the use case; keep in mind that syscalls are slow, too. If you have an application that does significant computation on lots of data (think a scientific calculation/simulation), having another core on the same socket read ahead from disk to RAM might be much more efficient than pausing computation to read synchronously. Or if you're a file server that is just passing things back to the kernel's network layer, you might not even need to see the contents of RAM yourself.

[ Parent | on HN ]