Deliberately leak PTDS thread_local events in stream ordered mr #1375
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
If an object with thread_local modifier has static storage duration, its destructor (if it exists) will run below main (https://eel.is/c++draft/basic.start.term). The CUDA runtime also sets up (when the first call into the runtime is made) a teardown of the driver that runs atexit. Although [basic.start.term#5](https://eel.is/c++draft/basic.start.term#5) provides guarantees on the order in which these destructors are called, it appears that no C++ stdlib implementation correctly implements this for thread_local objects with static storage duration. Moreover (possibly consequently) it is considered undefined behaviour to call into the CUDA runtime below main. Hence, we cannot call cudaEventDestroy to deallocate our thread_local events. Since there are a finite number of these event (ndevices * nparticipating_threads), rather than attempting to destroy them we choose to leak them, thus avoiding any sequencing problems. - Closes rapidsai#1371
harrism
requested changes
Nov 8, 2023
|
I couldn't think of a good way to test this (though locally it fixes the issue in #1371). |
harrism
approved these changes
Nov 8, 2023
wence-
commented
Nov 8, 2023
include/rmm/mr/device/detail/stream_ordered_memory_resource.hpp
Outdated
Show resolved
Hide resolved
jrhemstad
reviewed
Nov 8, 2023
include/rmm/mr/device/detail/stream_ordered_memory_resource.hpp
Outdated
Show resolved
Hide resolved
jrhemstad
approved these changes
Nov 8, 2023
|
@wence- if you want to make the two suggested changes above I think we can get this merged. |
Co-authored-by: Jake Hemstad <jhemstad@nvidia.com>
wence-
commented
Nov 8, 2023
include/rmm/mr/device/detail/stream_ordered_memory_resource.hpp
Outdated
Show resolved
Hide resolved
|
/merge |
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.
Description
An object with
thread_localmodifier has thread storage duration, its destructor (if it exists) will after the thread exits, which, on the main thread, is belowmain(https://eel.is/c++draft/basic.start.term). The CUDA runtime sets up (when the first call into the runtime is made) a teardown of the driver that runsatexit. Although basic.start.term#5 provides guarantees on the order in which these destructors are called (thread storage duration objects are destructed before anyatexithandlers run), it appears that gnu libstdc++ does not always implement this correctly (if not compiled with_GLIBCXX_HAVE___CXA_THREAD_ATEXIT).Moreover (possibly consequently) it is considered undefined behaviour to call into the CUDA runtime below
main. Hence, we cannot callcudaEventDestroyto deallocate ourthread_localevents. Since there are a finite number of these event (ndevices * nparticipating_threads), rather than attempting to destroy them we choose to leak them, thus avoiding any sequencing problems.thread_localstruct before intializing rmm in PTDS causes a cuda error at exit #1371Checklist