ggml-alloc: fix discrepency between measure&eval#2639
Merged
ggerganov merged 1 commit intoggml-org:masterfrom Aug 17, 2023
Merged
ggml-alloc: fix discrepency between measure&eval#2639ggerganov merged 1 commit intoggml-org:masterfrom
ggerganov merged 1 commit intoggml-org:masterfrom
Conversation
The GGML memory allocator consistently places a tensor within the optimal-fit memory block, which is the smallest block capable of accommodating the tensor's size. During the measurement phase, the final block is generously sized, ensuring it never qualifies as the optimal-fit block as long as there exists another block capable of accommodating the tensor. Nevertheless, in the evaluation phase, the last block is constrained in size and could potentially qualify as the optimal-fit block. Consequently, there exists the possibility of a tensor being allocated to a different region during evaluation, leading to more memory fragmentation in our scratch buffer. This recent commit guarantees uniform behavior of the allocator across both the measurement and evaluation phases, eliminating discrepancies between the two.
slaren
approved these changes
Aug 17, 2023
Member
slaren
left a comment
There was a problem hiding this comment.
Good fix, looks like this could be the cause of the issue with Metal, but I cannot reproduce it with the CPU backend.
Contributor
Author
|
In the context of Metal, it only triggered when using a reordered graph and a 70B model, which seems to be a corner case, I suppose. |
ggerganov
approved these changes
Aug 17, 2023
Member
ggerganov
left a comment
There was a problem hiding this comment.
Thank you for the detailed description!
Confirm the issue is fixed 👍
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
3 participants
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.
The GGML memory allocator consistently places a tensor within the optimal-fit memory block, which is the smallest block capable of accommodating the tensor's size. During the measurement phase, the final block is generously sized, ensuring it never qualifies as the optimal-fit block as long as there exists another block capable of accommodating the tensor. Nevertheless, in the evaluation phase, the last block is constrained in size and could potentially qualify as the optimal-fit block. Consequently, there exists the possibility of a tensor being allocated to a different region during evaluation, leading to more memory fragmentation in our scratch buffer in the evaluation phase.
This commit guarantees uniform behavior of the allocator across both the measurement and evaluation phases, eliminating discrepancies between the two.