151–160 of 177 posts
Kind of fascinating that slashing syscalls by ~35x (versus the `ls -la` benchmark) is "only" worth a 2x speedup
These syscalls are mostly through VDSO, so not very costly
Earlier quoted context omitted.
Curious: Why? Is it not a good fit for what ripgrep does? Isn't the sort of "streaming" "line at a time" I/O that ripgrep does a good fit for async io?
For many workloads, ripgrep spends the vast majority of its time searching through files. But more practically, it would be a terror to implement. ripgrep is built on top of platform specific standard file system APIs. io_uring would mean a whole heap of code to work with a different syscall pattern in addition to the existing code pattern for non-Linux targets. So to even figure out whether it would be worth doing t…
Earlier quoted context omitted.
For many workloads, ripgrep spends the vast majority of its time searching through files. But more practically, it would be a terror to implement. ripgrep is built on top of platform specific standard file system APIs. io_uring would mean a whole heap of code to work with a different syscall pattern in addition to the existing code pattern for non-Linux targets. So to even figure out whether it would be worth doing t…
I believe that io_uring does not support getdents (despite multiple patch series being proposed). So you'd get async stat(), if you need them, but nothing else.
I wonder how it performs against an NFS server with lots of files, especially one over a kinda-crappy connection. Putting an unreliable network service behind blocking POSIX syscalls is one of the main reasons NFS is a terrible design choice (as can be seen by anyone who's tried to ctrl+c any app that's reading from a broken NFS folder), but I wonder if io_uring mitigates the bad parts somewhat.
I did have a hell of a difficult time once with intermittent failures from a poorly seated network cable.
It's a shame to see uutils doing so poorly here. I feel like they're our best hope for an organization to drive this sort of core modernization forward, but 2x slower than GNU isn't a good start.
Earlier quoted context omitted.
> The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff I don't agree that it was a reasonable tradeoff. Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. I don't think this is unique to NFS, it applies to any network filesystem you try to present as if it's a local o…
> Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. It's the only idea though. We don't know how to make reliable systems, other than by cobbling together a lot of unreliable ones and hoping the emergent behaviour is more reliable than that of the parts.
No, there's math to calculate that without having to rely on hope.
Earlier quoted context omitted.
you give process direct access to a piece of kernel memory. its a reason why there is separation. thats all.
...don't you supply the memory in the submission queue? or do you mean the queues themselves?
https://github.com/ziglang/zig/blob/69cf40da600224734d39c6f6...
eza could catch up with lsr. Why is n=1.000 so slow with lsr ? Does io_uring add so much overhead ?