virtiofs: advertise multiple request queues for parallel I/O#3442
Open
benhillis wants to merge 2 commits intomicrosoft:mainfrom
Open
virtiofs: advertise multiple request queues for parallel I/O#3442benhillis wants to merge 2 commits intomicrosoft:mainfrom
benhillis wants to merge 2 commits intomicrosoft:mainfrom
Conversation
Advertise num_request_queues based on available host CPUs (capped at 16) instead of hardcoding 1. The Linux guest kernel (>=6.11) distributes FUSE requests across queues on a per-CPU basis, eliminating single-queue lock contention for parallel workloads. Each queue is serviced by an independent worker task, so requests on different queues are processed concurrently without contention. Older kernels that lack multi-queue support (< 6.11) will ignore the extra queues and continue using queue 0 — no behavioral change for them. The queue count is configurable via the new num_request_queues parameter on VirtioFsDevice::new(). Passing None uses the host CPU count heuristic. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the virtio-fs device to advertise multiple request queues (instead of always 1), using a host-CPU-based heuristic capped at 16. This enables parallel FUSE I/O in newer Linux guests that support virtio-fs multi-queue.
Changes:
- Add
MAX_REQUEST_QUEUES(16) and compute a defaultnum_request_queuesfromstd::thread::available_parallelism()when not explicitly provided. - Update virtio-fs device traits to advertise
max_queues = num_request_queues + 1. - Thread the new
num_request_queues: Option<u32>parameter through the resolver (default heuristic) and integration tests (forceSome(1)for determinism).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| vm/devices/virtio/virtiofs/src/virtio.rs | Adds configurable/default request-queue count and advertises the updated total queue count. |
| vm/devices/virtio/virtiofs/src/resolver.rs | Uses the new API parameter, defaulting to the heuristic (None). |
| vm/devices/virtio/virtiofs/src/integration_tests.rs | Pins queue count to Some(1) to keep tests deterministic. |
Member
Author
|
I'm currently benchmarking this with the current WSL kernel and the upcoming 6.18 kernel. Will provide numbers once I have them. |
Move .clamp(1, MAX_REQUEST_QUEUES) outside the unwrap_or_else closure so that explicitly-provided values (e.g. Some(0) or Some(100)) are also bounded. Previously only the heuristic path was clamped. Add three tests verifying the clamping behavior for None, Some(0), and Some(>MAX). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Comment on lines
+545
to
+550
| // num_request_queues should be at least 1 and at most MAX (16). | ||
| // max_queues = num_request_queues + 1 (hiprio queue). | ||
| assert!(traits.max_queues >= 2, "at least 1 request queue + hiprio"); | ||
| assert!( | ||
| traits.max_queues <= 17, | ||
| "at most 16 request queues + hiprio" |
Comment on lines
+574
to
+575
| // Some(100) should be clamped to MAX_REQUEST_QUEUES (16) → max_queues = 17 | ||
| assert_eq!(traits.max_queues, 17); |
Comment on lines
44
to
48
| )?, | ||
| 0, | ||
| None, | ||
| None, | ||
| ), |
Comment on lines
+67
to
+68
| /// queues on a per-CPU basis. If `None`, defaults to the number of | ||
| /// available CPUs (capped at 16). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Advertise
num_request_queuesbased on available host CPUs (capped at 16)instead of hardcoding 1. The Linux guest kernel (≥6.11) distributes
FUSE requests across queues on a per-CPU basis, eliminating single-queue
lock contention for parallel workloads.
Each queue is serviced by an independent worker task, so requests on
different queues are processed concurrently without contention. Older
kernels that lack multi-queue support (<6.11) will ignore the extra
queues and continue using queue 0 — no behavioral change for them.
The queue count is configurable via the new
num_request_queuesparameteron
VirtioFsDevice::new(). PassingNoneuses the host CPU count heuristic.Changes
virtio.rs: AddMAX_REQUEST_QUEUESconstant, compute queue count fromavailable_parallelism(), updatemax_queuestonum_request_queues + 1resolver.rs: PassNone(use default heuristic)integration_tests.rs: PassSome(1)for deterministic test behavior