You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
iotune uses nr_requests to select the iodepth to use for its IOPS-related benchmarks: it sums the nr_requests value from the involved disks (including the underlying devices if md is being used). However, nr_requests is not an upper bound on the amount of requests that can be in flight in a disk: see here for example:
... Note that nr_requests only applies to the I/O operations within the I/O scheduler and not to I/O operations already dispatched to the underlying device. Therefore, the maximum outstanding limit of I/O operations against a device is (nr_requests*2)+(queue_depth) where queue_depth is /sys/block/sdN/device/queue_depth, sometimes also referred to as the LUN queue depth. You can see this total outstanding number of I/O operations in, for example, the output of iostat in the avgqu-sz column.
This is actually noticeable when testing the same devices with fio: performance may keep increasing even as iodepth rises above the nr_requests value. Perhaps we should use the sum of the block device queue size + nr_requests. Or make it configurable.
The text was updated successfully, but these errors were encountered:
iotune uses nr_requests to select the iodepth to use for its IOPS-related benchmarks: it sums the
nr_requests
value from the involved disks (including the underlying devices ifmd
is being used). However,nr_requests
is not an upper bound on the amount of requests that can be in flight in a disk: see here for example:This is actually noticeable when testing the same devices with
fio
: performance may keep increasing even asiodepth
rises above thenr_requests
value. Perhaps we should use the sum of the block devicequeue
size +nr_requests
. Or make it configurable.The text was updated successfully, but these errors were encountered: