Topic/ompio pipeline iread iwrite3 #11383
Merged
Conversation
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
devreal
reviewed
Feb 8, 2023
edgargabriel
force-pushed
the
topic/ompio-pipeline-iread-iwrite3
branch
from
2d4b280 to
72b8758
Compare
|
@devreal thank you for your review and feedback (and sorry it took me so long to get to it), I think I addressed all items, except for the one question regarding the mutex before the loop. |
edgargabriel
force-pushed
the
topic/ompio-pipeline-iread-iwrite3
branch
2 times, most recently
from
efa13b3 to
784499f
Compare
devreal
approved these changes
Feb 20, 2023
Pipelined iread/iwrite operations require the notion of subrequests, i.e. a user level request can contain multiple internal subrequests that all have to complete before the user level operation is considered finished. This requires adjustments to the internal ompio progress engine and data structures. Note: this is purely just a pipelined algorithm, no overlap between different iterations. Extract the file view into a separate datastructure. This is required in the next step since we need to cache file view and position of the file pointer on the request. Replicate the file view and the file pointer position on the request. This is required to correctly increment where to read/write data for every subrequest, and handle the potential situation that the code changes the file after posting an iread/iwrite but before the operation finishes. Furthermore, when initiating an iread/iwrite we need to immidiatly move the position of the handle to the end of the operation, such that subsequent read/write operations use the correct position to start out with, and don't accidentaly interfere with the already ongoing non-blocking operation. Signed-off-by: Edgar Gabriel <[email protected]> Signed-off-by: Edgar Gabriel <[email protected]>
edgargabriel
force-pushed
the
topic/ompio-pipeline-iread-iwrite3
branch
from
784499f to
25b8dd2
Compare
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.
Second attempt at the pipelined iread/iwrite operations optimized for GPU buffers and external32 representation.
The current pr has three separate commits:
a. replicate the fileview structure from file handle onto the request. This way, the position calculated when posting the next segment from the progress engine is completely independent of what other operations on the file handle are currently ongoing. Hence, other iread/iwrite operations or e.g. setting the file view will not interfere with an already ongoing operation.
b. Move the file pointer on the file handle to the expected end of the operation after initiating the iread/iwrite. This way, subsequent read/write operations will continue where the iread/iwrite is expected to end, and not interfere (overwrite) ongoing operations - unless the user explicitly moves the file pointer back.