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?
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.
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.
Hanna
