The block worker currently completes every virtio-blk request synchronously before looking at the next available descriptor. On macOS, bursts of independent reads from large sparse raw images therefore pay host I/O latency one request at a time even when the guest has already queued substantial work.
Allow independent reads to share access to the existing imago FormatAccess by replacing its outer Mutex with an RwLock. Keep writes, flushes, discard, and write-zeroes exclusive so operations that mutate storage or invalidate mappings remain serialized.
For macOS raw images without direct I/O, collect consecutive queued read requests and service them with at most eight scoped worker threads. Bound a batch to 128 requests and 8 MiB, retain the synchronous path for batches smaller than eight requests, stop collection at the first non-read request, and publish completions in original queue order.
Keep qcow2, vmdk, direct-I/O, and non-macOS devices on the existing single-request path.
Add focused tests for read classification, ordered parallel results, and failed reads.
Assisted-by: ChatGPT:GPT-5.6 Sol
Activity
7
jakecorrenti1mo agoHi @RobertDeRose, thank you for the contribution!
IMO the scope of your solution is too narrow. We should be concerned about a more general solution that would fix virtio-blk read throughput. What's the specific use case you're trying to solve by gating this to only Raw disk images on macOS?
Coincidentally I was going to post a PR today with these changes: https://github.com/libkrun/libkrun/compare/main...jakecorrenti:libkrun:fix-824-virtio-blk-parallel-reads which is a more general solution for this exact thing. Let me know if you'd rather me post my changes and give it a thorough review.
RobertDeRose1mo agoHi @RobertDeRose, thank you for the contribution!
IMO the scope of your solution is too narrow. We should be concerned about a more general solution that would fix virtio-blk read throughput. What's the specific use case you're trying to solve by gating this to only Raw disk images on macOS?
Coincidentally I was going to post a PR today with these changes: main...jakecorrenti:libkrun:fix-824-virtio-blk-parallel-reads which is a more general solution for this exact thing. Let me know if you'd rather me post my changes and give it a thorough review.
I've been implementing a container-runtime for Apple's container using libkrun and this was the current root cause of a startup performance loss in my specific use-case.
Without this change, my runtime startup was about 6x slower than Apple's native VZ implementation, with this change libkrun is now either on par or even slightly faster on startup.
RobertDeRose1mo ago@jakecorrenti I also see that this patch is failing some code quality issues and the integration tests, if you think your change will also handle my needs then I'm OK for you to close this. I just found it was extremely helpful for my use-case and didn't have the time or resources to test all the other cases but wanted to contribute if it helped the project.
jakecorrenti1mo ago@jakecorrenti I also see that this patch is failing some code quality issues and the integration tests, if you think your change will also handle my needs then I'm OK for you to close this. I just found it was extremely helpful for my use-case and didn't have the time or resources to test all the other cases but wanted to contribute if it helped the project.
I'm cleaning it up as we speak, but if you're able to test out my branch for your use case that would be helpful to understand if there's anything missing in its current state.
slp1mo ago@RobertDeRose Could you please give #865 a try to see if it achieves similar performance in your use case?
please add
cherry-pick-1.19.5label