-
Notifications
You must be signed in to change notification settings - Fork 24.9k
Avoid potential deadlocks in host allocator #159352
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
base: gh/guangyey/174/base
Are you sure you want to change the base?
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/159352
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit 89aa54d with merge base 05c19d1 ( FLAKY - The following job failed but was likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
block->event_count_ += events->size(); | ||
// Move out streams to avoid holding the mutex during event recording | ||
streams = std::move(block->streams_); | ||
block->streams_.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved streams are used at the next line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually fine per the spec, std::move moves puts it an unspecified, but valid state. Clear() should be safe to call.
block->event_count_ += events->size(); | ||
// Move out streams to avoid holding the mutex during event recording | ||
streams = std::move(block->streams_); | ||
block->streams_.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually fine per the spec, std::move moves puts it an unspecified, but valid state. Clear() should be safe to call.
@guangyey , could you help rebase the stack to make the ci signal green? |
OK. |
Can you clarify when the GIL would get grabbed in this case? |
@albanD Take cuda for an example, here will grab the GIL at pytorch/aten/src/ATen/cuda/CUDAEvent.h Lines 140 to 146 in ca7315c
-> CONCRETE_GPU_TRACE pytorch/torch/csrc/PyInterpreter.cpp Lines 107 to 112 in ca7315c
and try to fetch GIL at line 26 pytorch/torch/csrc/PyInterpreter.cpp Lines 23 to 28 in ca7315c
|
Stack from ghstack (oldest at bottom):
Motivation
This PR fixes a potential deadlock in the host allocator.
When calling
event->record(stream)
, therecord_stream
implementation may acquire the Python GIL.In places such as
pytorch/aten/src/ATen/cuda/CachingHostAllocator.cpp
Lines 145 to 151 in 842cc77
pytorch/aten/src/ATen/xpu/CachingHostAllocator.cpp
Lines 22 to 28 in 842cc77
record_stream
is invoked while holding the allocator lock.To prevent deadlocks, we must ensure the locking order is:
GIL → Allocator Lock.
Reversing the order (Allocator Lock → GIL) can cause a deadlock.