Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
1–10 of 53 posts
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#2I remember when he first hit 1M when he was at Fusion-IO. Man how far things have come since those days.
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#3That's 125 ns per IO, on a single CPU core, with two devices. Mind boggling.
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#4That's 125 ns per IO, on a single CPU core, with two devices. Mind boggling.
IO is 512B sectors here? Or 4KiB?
EDIT: 512, looking at the screenshot..
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#5That's 125 ns per IO, on a single CPU core, with two devices. Mind boggling.
Faster than DRAM from the 90's.
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#6That's 125 ns per IO, on a single CPU core, with two devices. Mind boggling.
Faster than DRAM from the 90's.
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.
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#7I know this will be down voted but I've learned to be a bit skeptical of Axboe's monumental claims. There have been some unfair benchmarks posted in the past surrounding io_uring that were called out by people on the liburing repositories. Take these with a grain of salt - his results are notoriously very difficult to reproduce, even on identical hardware.
Nevertheless, io_uring is certainly the better design and I'm happy to see progress still being made.
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#8I know this will be down voted but I've learned to be a bit skeptical of Axboe's monumental claims. There have been some unfair benchmarks posted in the past surrounding io_uring that were called out by people on the liburing repositories. Take these with a grain of salt - his results are notoriously very difficult to reproduce, even on identical hardware. Nevertheless, io_uring is certainly the better design and I'm…
Nitpicking aside he has twenty years of Linux kernel development experience and does great things for everyones benefit. Congratulations Jens Axboe!
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#9Earlier quoted context omitted.
Faster than DRAM from the 90's.
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.
Re: Axboe Achieves 8M IOPS Per-Core with Newest Linux Optimization Patches
#10I know this will be down voted but I've learned to be a bit skeptical of Axboe's monumental claims. There have been some unfair benchmarks posted in the past surrounding io_uring that were called out by people on the liburing repositories. Take these with a grain of salt - his results are notoriously very difficult to reproduce, even on identical hardware. Nevertheless, io_uring is certainly the better design and I'm…
Nitpicking aside he has twenty years of Linux kernel development experience and does great things for everyones benefit. Congratulations Jens Axboe!
This wasn't nitpicking. It was claiming a nontrivial speedup over epoll for identical test cases. What was the point of your comment?