On 11/24/20 5:50 AM, David Howells wrote: > Pavel Begunkov <asml.silence@xxxxxxxxx> wrote: > >> fio is relatively heavy, I'd suggest to try fio/t/io_uring with nullblk > > no patches: Here's what I get. nullb0 using blk-mq, and submit_queues==NPROC. iostats and merging disabled, using 8k bs for t/io_uring to ensure we have > 1 segment. Everything pinned to the same CPU to ensure reproducibility and stability. Kernel has CONFIG_RETPOLINE enabled. 5.10-rc5: IOPS=2453184, IOS/call=32/31, inflight=128 (128) IOPS=2435648, IOS/call=32/32, inflight=64 (64) IOPS=2448544, IOS/call=32/31, inflight=96 (96) IOPS=2439584, IOS/call=32/31, inflight=128 (128) IOPS=2454176, IOS/call=32/32, inflight=32 (32) 5.10-rc5+all patches IOPS=2304224, IOS/call=32/32, inflight=64 (64) IOPS=2309216, IOS/call=32/32, inflight=32 (32) IOPS=2305376, IOS/call=32/31, inflight=128 (128) IOPS=2300544, IOS/call=32/32, inflight=128 (128) IOPS=2301728, IOS/call=32/32, inflight=32 (32) which looks to be around a 6% drop. Using actual hardware instead of just null_blk: 5.10-rc5: IOPS=854163, IOS/call=31/31, inflight=101 (101) IOPS=855495, IOS/call=31/31, inflight=117 (117) IOPS=856118, IOS/call=31/31, inflight=100 (100) IOPS=855863, IOS/call=31/31, inflight=113 (113) IOPS=856282, IOS/call=31/31, inflight=116 (116) 5.10-rc5+all patches IOPS=833391, IOS/call=31/31, inflight=100 (100) IOPS=838342, IOS/call=31/31, inflight=100 (100) IOPS=839921, IOS/call=31/31, inflight=105 (105) IOPS=841607, IOS/call=31/31, inflight=123 (123) IOPS=843625, IOS/call=31/31, inflight=107 (107) which looks to be around 2-3%, but we're also running at a much slower rate (830K vs ~2.3M). -- Jens Axboe
