Re: [PATCH] backend: correctly handle rate_iops combined with bssplit

On 2026/03/10 21:58, Dmitry Fomichev wrote:
> Currently, rate_iops does not produce the expected I/O rate with
> workloads that use 'bssplit' option. Consider the following example
> configuration -
> 
> [global]
> direct=1
> time_based
> runtime=30s
> ioengine=io_uring
> thread=1
> 
> [bssplit_rate_iops_repro]
> filename=/dev/sdX
> rw=randread
> iodepth=8
> bs=64K
> rate_iops=50
> 
> This works correctly and ~50 IOPS I/O rate is logged during the run.
> 
> If we replace 'bs=64K' with the following bssplit option -
> 
> bssplit=32ki/20:64ki/40:256ki/10:512ki/25:1mi/5
> 
> in the configuration above, then some incorrect (much lower) IOPS values
> are observed to be in effect at run time.
> 
> This problem happens because fio, in order to derive the required
> I/O rate from 'rate_iops' value provided by the user, simply multiplies
> the IOPS value by the minimum block size (min_bs). Once bps I/O rate is
> calculated this way, the processing for 'rate' and 'rate_iops' becomes
> identical.
> 
> This works if the I/O issued has the uniform min_bs, as in case of using
> 'bs=64K'. However, with 'bssplit' option in effect, fio may issue I/O
> with sizes that are much different from min_bs. Yet the code in
> usec_for_io() currently always calculates I/O issue delays based on
> min_bs leading to incorrect IOPS being produced.
> 
> Fix this by modifying usec_for_io() function to check for
> bssplit+rate_iops being in effect. For this case, derive the IOPS rate
> from bps 'rate' member of thread data and then calculate the delay to
> the next I/O using the IOPS value, not the bps rate.
> 
> Signed-off-by: Dmitry Fomichev <[email protected]>

Looks good.

Reviewed-by: Damien Le Moal <[email protected]>


-- 
Damien Le Moal
Western Digital Research