On Wed, Sep 16, 2026 at 02:04:58PM +0200, Hanna Czenczek wrote: > On 16.09.26 10:14, Hanna Czenczek wrote: > > On 03.09.26 16:23, Stefan Hajnoczi wrote: > > > On Mon, Aug 31, 2026 at 03:52:02PM +0200, Hanna Czenczek wrote: > > > > When a request finishes with a higher latency than a predefined > > > > threshold, emit the BLOCK_IO_DELAY event. > > > > > > > > Note there would be an alternative, more precise solution: We > > > > could keep > > > > all active cookies per BlockBackend in a list and repeatedly iterate > > > > over it in a background coroutine (woken on a timer so it would wake > > > > always exactly when the next request would time out, so it generally > > > > stays asleep until there is actually a timeout). This way, we > > > > could emit > > > > the event exactly when a request crosses the delay threshold, while it > > > > is still running; and we could hypothetically even take actions like > > > > pausing the VM until the request is done so the guest operating system > > > > is shielded from extreme latency spikes. > > > > > > > > In practice, this is very complicated because latency cookies are > > > > created and finalized all over the place, so it is very hard to > > > > guarantee that every `block_acct_start()` is matched by the right > > > > finalization to ensure that cookies are properly removed from the list > > > > when they are done. Even if we fix all non-matching places now, > > > > there is > > > > hardly a guarantee this will be kept in order in the future. > > > I think this patch series already couples the accounting so closely with > > > BlockBackend (i.e. adding the offset field into the cookie struct and > > > adding a BB pointer into the stats struct) that we might as well fully > > > integrate the two. Then callers don't need to manually manage cookies > > > because BlockBackend does that internally and the concerns about > > > lifetimes go away. > > > > I don’t follow how integrating them into BlockBackend automatically > > solves the problem. > > > > Are you suggesting that blk_* I/O functions should do the accounting > > instead of the device emulation code?
Yes. > > The thing is, AFAIU, doing that would cause changes in behavior, because the > hardware device requests don’t always line up with the BB requests. Did you find a fundamental incompatibility that rules out letting the block layer handles stats for blk_aio_*()? > What I could do would be to abandon the cookie-based approach altogether, of > course; instead creating a completely different tracking object in those BB > functions and put those into a list. And then we could decide at a later > point if we want to integrate cookies with that. The only downside I see is > that this would mean the latency reporting would not line up with the > requests reported in the stats, or the histogram. The tracking object could be a timer! :) Stefan
signature.asc
Description: PGP signature
