You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
crtrott
added
Blocks Promotion
Overview issue for release-blocking bugs
Bug
Broken / incorrect code; it could be Kokkos' responsibility, or others’ (e.g., Trilinos)
labels
Feb 26, 2020
Found it. This is a general bug, not just for that system :-(. View Initialization was only ever using default index type for its execution policy, which means 32bit indices internally. So when you hand it a size_t with the correct larger than 2B value you are in trouble. Have a fix coming ... .
Note this is not memory size larger than 2GB, but more than 2B elements (i.e. typically 8GB or 16GB allocations). The only realistic way to get in trouble on Summit or Sierra is probably with allocation a view of char. But on the 32GB Volta cards inside of DGX boxes it is not totally outside of what one can imagine, that a big graph with more than 2B elements gets allocated maybe, i.e. the list of all edges or so as a Nx2 array with N>1B.
@crtrott the fix from #2819 did not resolve the hang+timeout in view_64bit tests on White.
This still occurs with cuda/9.2.88+gcc/7.2.0 builds with UVM enabled.
This was detected on the White testbed (Power8+Kepler37) when enabling the large_memory_tests in nightlies.
Reproducer instructions (UVM enabled):
The text was updated successfully, but these errors were encountered: