Am 21.09.2026 um 22:42 hat Stefan Hajnoczi geschrieben: > 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. :/
What's even stranger is that both things were introduced in the same commit. But it seems clearly related to 136 because the change was made right before the test was added. Berto, do you remember why you didn't rely just on clock_step? I suppose we could just try to change the behaviour and fix up 136. Behaviour under qtest is something I'd be okay with changing. Kevin
signature.asc
Description: PGP signature
