drivers/nvme: deepen the IO queue and PRP-list cache for concurrent load - #1479
Open
gburd wants to merge 1 commit into
Open
drivers/nvme: deepen the IO queue and PRP-list cache for concurrent load#1479gburd wants to merge 1 commit into
gburd wants to merge 1 commit into
Conversation
Under a concurrent database workload on native NVMe the IO submission queue (depth 64) filled quickly, so submitting threads blocked on the sq-full wait and I/O serialized -- throughput stayed flat and latency grew with concurrency while the CPUs sat idle waiting for completions. Deepen the IO queue to 256 entries (still clamped to the device's advertised cap.mqes in create_io_queues, so it is safe on controllers with a smaller limit) so many more requests stay in flight concurrently. Grow the per-queue PRP-list cache from 16 to 128 to match, avoiding alloc_page churn on the submit path of a deep busy queue (a miss still falls back to alloc and a full pool frees on return, so this is a churn optimization, not a correctness change).
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
1 participant
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.
Problem
The NVMe driver created IO submission queues 64 entries deep and pre-allocated
only 16 PRP-list pages per queue. Under a concurrent workload that keeps many
I/Os in flight, a 64-deep queue fills quickly and submitting threads then block
on the sq-full wait, limiting how much I/O can be outstanding at once.
Fix
Deepen the IO queue to 256 entries. This stays clamped to the device's
advertised maximum (
cap.mqes) increate_io_queues(), so it is safe oncontrollers with a smaller queue-entry limit and simply uses more of the depth
the device already offers. Grow the per-queue PRP-list cache from 16 to 128 to
match, so a deep busy queue rarely misses into
alloc_page()on the submitpath; a miss still falls back to allocation and a full pool frees on return, so
this is a churn optimization rather than a correctness change.
Testing
Built and booted; NVMe I/O continues to work with the deeper queue. The change
is conservative (bounded by the device's own
cap.mqes) and touches only queuesizing.