-
Notifications
You must be signed in to change notification settings - Fork 44
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
Evaluate impact of JIT deserialization during CUDA object spilling #162
Comments
As a baseline, we ran every query 5 times on a standard cluster 8 GPUs of a DGX-2 with a 15GB device memory limit and 30GB RMM pool. With
|
Sorry for the late reply, I wasn't aware of this issue :/ Having said that, I am debugging a deadlock with the new JIT spilling that Q02 triggers when the device limit is 15GB (as opposed to the 20GB, which I have been using when testing). Will let you know when I have a fix. |
CC: @ChrisJar for awareness. |
Fixes a deadlock where multiple threads accesses `ProxifyHostFile.maybe_evict()` but none of them can acquire both the `ProxifyHostFile` lock and the `ProxyObject` lock simultaneously. Should fix_ rapidsai/gpu-bdb#162 (comment) Authors: - Mads R. B. Kristensen (@madsbk) Approvers: - Peter Andreas Entschev (@pentschev) URL: #501
The deadlock issue should be fixed in the latest version of dask-cuda rapidsai/dask-cuda#501 |
This functionality is now optionally available in nightlies, and we should evaluate how this affects performance (particularly with UCX).
The text was updated successfully, but these errors were encountered: