-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make a local copy of CUB's CachingDeviceAllocator and patch it for the race condition #240
Make a local copy of CUB's CachingDeviceAllocator and patch it for the race condition #240
Conversation
This commit fixes a race for the CUDA event between DeviceFree() and DeviceAllocate(). If the mutex is unlocked before the cudaEventRecord(), there is a short period of time when - the memory block is already in the free list (cached_blocks), and - the CUDA event status is not yet cudaErrorNotReady and the DeviceAllocate() may consider that memory block to be free to be used for another CUDA stream.
Validation summaryReference release CMSSW_10_4_0_pre4 at d74dd18
|
No changes in physics performance (as expected):
|
No changes in throughput: before
after
|
This commit fixes a race for the CUDA event between DeviceFree() and DeviceAllocate(). If the mutex is unlocked before the cudaEventRecord(), there is a short period of time when - the memory block is already in the free list (cached_blocks), and - the CUDA event status is not yet cudaErrorNotReady and the DeviceAllocate() may consider that memory block to be free to be used for another CUDA stream.
Given the simple commit history, I have tried merging this PR using the "Rebase and merge" approach instead of the usual "Squash and merge". The positive aspect is that it keeps the full git log history, i.e. it looked like this:
The negative aspect is that there is no trace of the PR number in the git log.
What do people like best ?
|
Ciao @fwyzard |
I'd prefer squash or rebase over the merge (since we're not the upstream repo, and "random" merges tend to make the history, and later comparisons/ports to upstream more difficult). I also think the PR number in the commit message(s) do(es) have some value (especially since we have those already in the history). So I suppose my preference would be
|
@makortel thanks for your comments, I think I agree with you. |
As discussed in #237.