On 22.09.26 19:18, Stefan Hajnoczi wrote:
On Tue, Sep 22, 2026 at 03:31:49PM +0200, Kevin Wolf wrote:
Am 21.09.2026 um 22:41 hat Stefan Hajnoczi geschrieben:
On Wed, Sep 16, 2026 at 10:04:51AM +0200, Hanna Czenczek wrote:
On 03.09.26 16:08, Stefan Hajnoczi wrote:
On Mon, Aug 31, 2026 at 03:51:56PM +0200, Hanna Czenczek wrote:
The problem is that if the destructor has to be called explicitly, we may
forget to do so; and accounting is done on the device emulation level, so
there is no central place where the pairing of constructor and destructor
would be obvious and trivial to verify.
This is the part I'm asking about: can accounting be done by the block
layer? There might be cases that are purely handled in device emulation
code without a call into the block layer. In that case the accounting
still needs to be done in device emulation code. But when device
emulation calls blk_aio_*(), it should not do accounting itself.
Apart from cases where requests are completed entirely within the
device (like for all block_acct_invalid() callers), there are also cases
where a single device-level requests involves multiple backend-level
requests. I was thinking of IDE TRIM initially, but actually I think
splitting can happen for any request that uses the DMA helpers.
Conversely, virtio-blk can merge requests, so you get a single request
in the backend that covers multiple requests in the device.
Sticking to the requests as seen by the device seems like the cleanest
solution rather than cheating and counting host requests in some places.
The idea to move the accounting into blk_aio_*() doesn't work well in
light of this.
Does this mean you would be against separating delay monitoring from the
rest of accounting?
Because to me that still sounds reasonable: To do delay monitoring in
the BB layer, separate from accounting cookies, to have a simple
lifecycle and timely reporting.
(And as you did say, if one wants the guest-device-request-level delay
information, the histogram is there O:) )
Hanna
