Maintain pending io_uring ops count for early return on run_once #349
Conversation
This file contains 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
|
@pereman2 Can you please have a look at this? |
penberg
added a commit
that referenced
this pull request
Sep 26, 2024
This is not related to any open issue (atleast from the ones I saw). This is related to an issue I saw when running the simulator as it was calling `io.run_once()` even before submitting any read/write job. This would lead to it hanging since io_uring's submit_and_wait would keep waiting for a completion event. I've tried to improve the simulator's IO handling a bit: We inject a fault before calling next_row() through which we'll get pread faults. Also we call io's run_once on getting RowResult::IO. This is run with a fault probability of 1%. This is less because a fault here would result us in terminating the entire loop iterating on rows, and also because realistically we'll expect less faults here. PS: I think run_once() should not hang either when no operation is pending in io_uring. Opened #349 for fixing that. Closes #348
pereman2
reviewed
Sep 27, 2024
Add a `pending_ops` field to `InnerLinuxIO` struct which is incremented for each operation submitted to the ring and decremented when they are taken off the completion queue. With this, we can exit from run_once if there are no pending operations. Otherwise, in that case, it would hang indefinitely due to call of `ring.submit_and_wait(1)`
arpit-saxena
force-pushed
the
no_hang_run_once
branch
from
cadf9a4 to
a7d735d
Compare
Adds a struct WrappedIOUring which contains a IoUring and a pending_ops field. Entry submission and popping from the queue is done through functions operating on it, which also maintains pending_ops count NOTE: This is a bit weird/hacky since in get_completion we create a CompletionQueue and just call its next(). If it were a normal iterator it would always return the same first item. However it is a queue posing as an iterator which makes this work.
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.
Add a
pending_opsfield toInnerLinuxIOstruct which is incremented for each operation submitted to the ring and decremented when they are taken off the completion queue. With this, we can exit from run_once if there are no pending operations. Otherwise, in that case, it would hang indefinitely due to call ofring.submit_and_wait(1)