Repository navigation
Conversation
Collaborator
Author
|
Perhaps 'related' isn't the correct term here -- they're both Windows concurrency bugs, I was looking through previous issues to see if there was already a fix for this one and found #283. They're not actually related in terms of the code or fixes. |
This branch has not been deployed
This file contains hidden or 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
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.
./openblas_commit.txt. If I did not update./openblas_commit.txt, I incremented the wheel build number (i.e. 0.3.29.0.0 to 0.3.29.0.1)Note: update
./openblas_commit.txtwithcd OpenBLAS; git describe --tags --abbrev=8 > ../openblas_commit.txtSummary
Update OpenBLAS to
v0.3.34-497-g791b02a1This picks up OpenMathLib/OpenBLAS#6105 ("Default allocator speedup"), which fixes a memory-corruption crash. If more buffers are in use at once than the main table holds (
2 * NUM_THREADS * NUM_PARALLEL),blas_memory_alloc()falls back to an overflow area. Each overflow allocation then mapped a new buffer instead of reusing the slot's buffer. It also calledblas_release_register()with no bound check, so afterNUM_BUFFERS + NEW_BUFFERSmappings it wrote past the end ofnew_release_info. This was seen on Windows ARM64 with many concurrent BLAS callers. The same PR also fixes two overflow-area races.I pinned the #6105 merge commit rather than develop HEAD to keep the bump focused. PRs merged after that are mostly Reference-LAPACK syncs. Let me know if you would prefer to move to HEAD instead.
Raise
NUM_THREADSfrom 24 to 64 on WindowsThis matches the Linux/macOS builds (
tools/build_steps.shalready uses 64). With 24, the main buffer table has only 48 slots, so applications with more concurrent callers reach the overflow path much sooner. That is the path that was crashing. I know a higherNUM_THREADSwas declined before over memory use (#97). Linux and macOS have used 64 for a while, and the main buffers are only mapped on first use.Related: #283 (win_amd64 crash with concurrent dgemm + dgemv).
Note: #248 removes
build_steps_win_arm64.batand movesNUM_THREADS=24intobuild_steps_windows.sh. Whichever PR merges second will need to keep 64.