On Wed, Sep 16, 2026 at 10:21:22AM +0200, Hanna Czenczek wrote: > On 03.09.26 17:08, Stefan Hajnoczi wrote: > > On Mon, Aug 31, 2026 at 03:52:04PM +0200, Hanna Czenczek wrote: > > > I am not quite sure why `latency_ns` is overridden by a fixed value in > > > qtest mode because personally, I find it much better if I can > > > individually change requests' latency by modifying the qtest clock. > > It looks like tests/qemu-iotests/136 relies on a hardcoded constant so > > it can check min/max/avg against known values. > > > > > But I'm not going to change existing behavior for the histogram and > > > such, so I will just move this override after the latency has been > > > evaluated regarding a potential BLOCK_IO_DELAY event. > > That's fine if you aren't taking the same testing approach as > > tests/qemu-iotests/136. I think the benefit of hardcoding the value for > > testing is that it would become possible to trigger the latency > > threshold without worrying about timing in the test environment. > > FWIW, as far as I understand, in qtest mode, `clock_type` is > `QEMU_CLOCK_VIRTUAL`, so it is not dependent on the test environment anyway, > but on the qtest clock. That’s why I don’t understand the fixed latency > value, but maybe it was just easier this way for 136 because this way it > does not have to do a clock_step for each request.
Yes, I think you're right. I'm not sure either. :/ Stefan
signature.asc
Description: PGP signature
