Looking into it more, what seems to be going on is that after writing td->o.size bytes, a time_based job silently closes all open files, resets, and starts over. Part of the process of resetting involves re-seeding all the random numbers. It seems like there are other implications to the reset as well. For example, in async ioengines it drains all the remaining IO, which results in less throughput. Potentially latency numbers could be effected as well, either positively or negatively. Would it make sense, for time_based runs, to not break out of the loop in do_io() so the state doesn't get reset? This would also allow the removal of the check in keep_running() for time_based, which would then allow "time_based" and "loops" to be used together in a meaningful way. At first blush, this would probably just be a case of adding "|| (td->o.time_based)" to the loop condition in do_io(), and that certainly addressed the case of random IO whe norandommap I initially saw. But the same performance issues could apply to sequential loads and random mapped loads, and just changing the loop condition didn't have any effect on that. There is something else which is determining that the end condition is met for sequential loads, read_iolog loads, and randommap loads. (For read_iolog loads, time_based and loops have no effect, so I'm not sure the value of changing that.) Would it be difficult to change the behavior so only loops= causes do_io() to be called repeatedly like that? -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
