-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[Hexagon] Use single allocation to back 2-d arrays #10903
Conversation
To maintain alignment of each individual region, padding may be added to the single allocation. As a result, this PR is dependent on functionality introduced in #10878 |
Current CI failures are the expected differences at the C++ side, which are resolved in #10878. No changes expected to be needed for them, but will need to relaunch CI once it lands.
|
Currently, each allocation allocates an entire page, so even a relatively small number of allocations can use very large amounts of VTCM. This commit changes calls to `AllocVtcmWorkspace` of shape `[N,M]` from performing `N` allocations of size `M`, to 1 allocation of size `N*M`. Since `N` is usually much smaller than a page, this reduces the total amount of memory required. This is an intermediate step, where the long-term solution is to use static planning for VTCM allocations. This returns the same `void**` type as the static planning eventually will, but avoids excess memory use in the meantime.
Previously, when a single monolithic allocation is used to back a 2-d Hexagon buffer of shape `[nallocs, nbytes_per_allocation]`, the allocation itself is aligned, but each individual region is not. This commit ensures that each individual region also followed the alignment specified.
2db1475
to
42e6e85
Compare
Rebased onto main to restart CI. |
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 is a great way to handle separate allocations, thanks @Lunderberg
* [Hexagon] Use single allocation to back 2-d arrays Currently, each allocation allocates an entire page, so even a relatively small number of allocations can use very large amounts of VTCM. This commit changes calls to `AllocVtcmWorkspace` of shape `[N,M]` from performing `N` allocations of size `M`, to 1 allocation of size `N*M`. Since `N` is usually much smaller than a page, this reduces the total amount of memory required. This is an intermediate step, where the long-term solution is to use static planning for VTCM allocations. This returns the same `void**` type as the static planning eventually will, but avoids excess memory use in the meantime. * [Hexagon] Maintain alignment of allocations Previously, when a single monolithic allocation is used to back a 2-d Hexagon buffer of shape `[nallocs, nbytes_per_allocation]`, the allocation itself is aligned, but each individual region is not. This commit ensures that each individual region also followed the alignment specified.
* [Hexagon] Use single allocation to back 2-d arrays Currently, each allocation allocates an entire page, so even a relatively small number of allocations can use very large amounts of VTCM. This commit changes calls to `AllocVtcmWorkspace` of shape `[N,M]` from performing `N` allocations of size `M`, to 1 allocation of size `N*M`. Since `N` is usually much smaller than a page, this reduces the total amount of memory required. This is an intermediate step, where the long-term solution is to use static planning for VTCM allocations. This returns the same `void**` type as the static planning eventually will, but avoids excess memory use in the meantime. * [Hexagon] Maintain alignment of allocations Previously, when a single monolithic allocation is used to back a 2-d Hexagon buffer of shape `[nallocs, nbytes_per_allocation]`, the allocation itself is aligned, but each individual region is not. This commit ensures that each individual region also followed the alignment specified.
* [Hexagon] Use single allocation to back 2-d arrays Currently, each allocation allocates an entire page, so even a relatively small number of allocations can use very large amounts of VTCM. This commit changes calls to `AllocVtcmWorkspace` of shape `[N,M]` from performing `N` allocations of size `M`, to 1 allocation of size `N*M`. Since `N` is usually much smaller than a page, this reduces the total amount of memory required. This is an intermediate step, where the long-term solution is to use static planning for VTCM allocations. This returns the same `void**` type as the static planning eventually will, but avoids excess memory use in the meantime. * [Hexagon] Maintain alignment of allocations Previously, when a single monolithic allocation is used to back a 2-d Hexagon buffer of shape `[nallocs, nbytes_per_allocation]`, the allocation itself is aligned, but each individual region is not. This commit ensures that each individual region also followed the alignment specified.
* [Hexagon] Use single allocation to back 2-d arrays Currently, each allocation allocates an entire page, so even a relatively small number of allocations can use very large amounts of VTCM. This commit changes calls to `AllocVtcmWorkspace` of shape `[N,M]` from performing `N` allocations of size `M`, to 1 allocation of size `N*M`. Since `N` is usually much smaller than a page, this reduces the total amount of memory required. This is an intermediate step, where the long-term solution is to use static planning for VTCM allocations. This returns the same `void**` type as the static planning eventually will, but avoids excess memory use in the meantime. * [Hexagon] Maintain alignment of allocations Previously, when a single monolithic allocation is used to back a 2-d Hexagon buffer of shape `[nallocs, nbytes_per_allocation]`, the allocation itself is aligned, but each individual region is not. This commit ensures that each individual region also followed the alignment specified.
Currently, each allocation allocates an entire page, so even a relatively small number of allocations can use very large amounts of VTCM. This commit changes calls to
AllocVtcmWorkspace
of shape[N,M]
from performingN
allocations of sizeM
, to 1 allocation of sizeN*M
. SinceN
is usually much smaller than a page, this reduces the total amount of memory required.This is an intermediate step, where the long-term solution is to use static planning for VTCM allocations. This returns the same
void**
type as the static planning eventually will, but avoids excess memory use in the meantime.