DO NOT MERGE: nvme_driver: delay io queue create to be post restore iff there are no ouststanding IO to that queue (#2456) #2495
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.
Clean cherry pick of PR #2456.
Looking at production data, I found that restoring the IO queues took
significantly longer than I expected. In those same runs, there was no
outstanding IO to those queues at the time of save. Since there's no
outstanding IO, there's no need to create the IO queue at restore time:
the purpose of creating the queue would be to handle completions. No
pending commands means no completions.
This won't help in the case where every IO QP has outstanding commands,
but it will help in cases where there are idle devices. And,
philosophically, we want to do as little during VP blackout as we can
get away with.