41–50 of 53 posts
He just hit 9M https://twitter.com/axboe/status/1450188650852065291
Anyone know exactly how to replicate this? I see the command line, but it looks like t/io_ring is maybe a wrapper around fio? Or maybe a binary/git repo so I can compile my own?
That's 125 ns per IO, on a single CPU core, with two devices. Mind boggling.
At around 4 GHz and 2 IPC, it's about 1000 CPU instructions per I/O. Assuming you have an hardware DMA ring buffer for I/O that is directly mapped in userspace, the only thing that is really needed is to write the operation type, size, disk position and memory position to the ring buffer, update the buffer position and check for flush, doable in around 8 CISC instructions (plus the slowpath), so around 100x inefficie…
This type of thing is not measured in instructions anymore, it's measured in off-board operations and latencies. Cache misses, latencies to poke MMIO and get back interrupts if necessary, DMA transfer to complete, device access time. In this case it seems the hardware is theoretically capable of about 12M so the core mostly be just waiting for that.
That's 125 ns per IO, on a single CPU core, with two devices. Mind boggling.
At around 4 GHz and 2 IPC, it's about 1000 CPU instructions per I/O. Assuming you have an hardware DMA ring buffer for I/O that is directly mapped in userspace, the only thing that is really needed is to write the operation type, size, disk position and memory position to the ring buffer, update the buffer position and check for flush, doable in around 8 CISC instructions (plus the slowpath), so around 100x inefficie…
Earlier quoted context omitted.
Sure. https://github.com/axboe/liburing/issues/189 Original claims were in the 90% and above performance increase over epoll. Then issues were found, and the figure was adjusted to 60% over epoll. Then more issues were found, and now real-world performance tests are showing minimal speedups if any. Unfortunately the sibling commentors don't see "computer science" as a science but instead as a "feel good hobby", it se…
Why did you omit the response you received from a netty developer that showed a large performance improvement[1]? Focusing entirely on the few cases where people report regressions and ignoring all of the reports of improvements isn't a good way to make an objective assessment. [1] https://github.com/netty/netty/issues/10622#issuecomment-701...
Earlier quoted context omitted.
Sure. https://github.com/axboe/liburing/issues/189 Original claims were in the 90% and above performance increase over epoll. Then issues were found, and the figure was adjusted to 60% over epoll. Then more issues were found, and now real-world performance tests are showing minimal speedups if any. Unfortunately the sibling commentors don't see "computer science" as a science but instead as a "feel good hobby", it se…
If that's the best example you've got I'm writing your entire comment off as a steaming pile of FUD.
Earlier quoted context omitted.
It is a wlel kwnon pohnnomeen taht you can sawp all the ltteers in a wrod and as lnog as the fsrit and lsat is ccrreot it wlil sitll be cibemreplohnse. https://www.mrc-cbu.cam.ac.uk/people/matt.davis/cmabridge/
It's wild that I was able to read that in my head at full speed, with the correct word pronunciation (except the last word... wonder what the upper limit on that is anyway?)
Earlier quoted context omitted.
If that's the best example you've got I'm writing your entire comment off as a steaming pile of FUD.
It's FUD to have personally run benchmarks across a number of platforms and machines and have seen very trivial, if any, speedup?
Earlier quoted context omitted.
The access time has actually not changed a lot, it's just that transferring the smallest read a contemporary processor would issue - one cache line (~64 bytes) - at somewhere between 500-1000 MB/s takes around 100 ns already. That transfer-related latency has been reduced drastically.
Didn't /RAS timing drop from like 120ns to 10ns too? That's what I was thinking about. Then DDR, and that bus size is also 16 times wider.
I look forward to a faster `cp` command.
The fastest `cp` is actually doing no data copies at all (relying on copy-on-write), on filesystems with reflink support. Incidentally, coreutils v9.0 cp switched to doing reflinks by default [1], so there's already a faster cp. [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=2...
Earlier quoted context omitted.
The fastest `cp` is actually doing no data copies at all (relying on copy-on-write), on filesystems with reflink support. Incidentally, coreutils v9.0 cp switched to doing reflinks by default [1], so there's already a faster cp. [1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=2...
True. But, but, … BUT when it comes to files found on differing (physical/logical/virtual) disk partitions, ye gonna need that block copying mechanism within ‘cp’.
There are also optimizations on other layers, e.g. transparent compression (e.g. btrfs) and online block-level dedup (e.g. dm-vdo), that can aid in minimizing and/or avoiding actual block copies.
When all else fails, cp will anyway fallback to buffered IO, so it won't be bound by the rate of IO (as long as writeback can keep up with memory pressure).
Of course improvements on all layers are always welcome and there are certainly workloads that can benefit from an optimized raw throughput, low-latency and scalability. Demanding workloads are typically using dedicated IO stacks and bypass the kernel altogether (e.g SPDK), but the amazing efforts of Axboe and everyone else in the kernel community have been continuously bringing linux up to par in terms of IO performance.
[1] https://man7.org/linux/man-pages/man2/copy_file_range.2.html [2] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4...