3 ms·
I bet if this article were written in 2020, they'd throw io_uring into the comparison. Does it allow directly returning the page cache memory without kernel cop
by scottlamb 6y ago
I bet if this article were written in 2020, they'd throw io_uring into the comparison. Does it allow directly returning the page cache memory without kernel copying also? I expect so (since it's a modern, performance-oriented interface) but don't know the details of how the buffer management works—seems like the kernel would have to supply the buffer then, it'd have to be at least page size, etc.
If so, it should have a similar benefit as what this article describes for mmap: either your program can completely avoid copying or it can do so in userspace with SIMD instructions.
- scottlamb 6y agoAlso, even when io_uring does copying in kernelspace, I wonder if it'd be more practical for it to use AVX instructions than from within a read syscall. As I understand it, userspace<->kernel transitions are lighter-weight than full context switches between processes. As discussed here: not saving/restoring the SIMD registers. (I think a bunch of other ways, too, like not replacing all the memory mappings.) There are also a bunch of pure-kernel processes (I don't know the terminology) shown on ps in square brackets, like [kthreadd], [rcu_gp], [rcu_par_gp], etc. I think a full context switch happens on entry/exit to one of these, just as between two different userspace processes. If the io_uring work always happens within one of these (does it?), the SIMD registers are already being saved/restored, and it'd be safe for it to use an avx_memcpy variant without paying any additional cost.