When performing tests at various block size, it's sometimes a bit
difficult to estimate if we reach the limit of the datapath.
This commit offer to simply prints the resulting bandwitdh of the IOPS
multiplied by the block size.
A typical output looks like :
[user@hosŧ] t/io_uring -b512 -d128 -c32 -s32 -p1 -F1 -B1 -n4 /dev/nvme0n1
...
IOPS=729856, BW=356 MiB/s, IOS/call=32/32, inflight=(105 119 108 109)
[user@host] t/io_uring -b4096 -d128 -c32 -s32 -p1 -F1 -B1 -n4 /dev/nvme0n1
...
IOPS=746368, BW=2915 MiB/s, IOS/call=32/31, inflight=(121 115 122 122)
In the 4K case, as for a PCI Gen3 product, we are clearly limited by the
bandwidth while in the 512 case we hit latency issues.
BW is expressed in MiB/sec.
Signed-off-by: Erwan Velu <e.velu@criteo.com>
unsigned long this_reap = 0;
unsigned long this_call = 0;
unsigned long rpc = 0, ipc = 0;
+ unsigned long iops;
sleep(1);
for (j = 0; j < nthreads; j++) {
} else
rpc = ipc = -1;
file_depths(fdepths);
- printf("IOPS=%lu, IOS/call=%ld/%ld, inflight=(%s)\n",
- this_done - done, rpc, ipc, fdepths);
+ iops = this_done - done;
+ printf("IOPS=%lu, BW=%luMiB/s, IOS/call=%ld/%ld, inflight=(%s)\n",
+ iops, iops * (1048576 / bs), rpc, ipc, fdepths);
done = this_done;
calls = this_call;
reap = this_reap;