| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the GPU allocators to common/mm/ since the allocators are common
code across all GPUs. Also rename the allocator code to move away from
gk20a_ prefixed structs and functions.
This caused one issue with the nvgpu_alloc() and nvgpu_free() functions.
There was a function for allocating either with kmalloc() or vmalloc()
depending on the size of the allocation. Those have now been renamed to
nvgpu_kalloc() and nvgpu_kfree().
Bug 1799159
Change-Id: Iddda92c013612bcb209847084ec85b8953002fa5
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: http://git-master/r/1274400
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an optimization to the bitmap allocator for handling sequences of
allocations. A common pattern of allocs from the priv_cmdbuf is to do
many allocs and then many frees. In such cases it makes sense to store
the last allocation offset and start searching for the next alloc from
there. For such a pattern we know that the previous bits are already
allocated so it doesn't make sense to search them unless we have to.
Obviously, if there's no space found ahead of the precious alloc's block
then we fall back to the remaining space.
In random allocation patterns this optimization should not have any
negative affects. It merely shifts the start point for searching for
allocs but assuming each bit has an equal probability of being free the
start location does not matter.
Bug 1799159
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: http://git-master/r/1205958
(cherry picked from commit 759c583962d6d57cb8cb073ccdbfcfc6db4c1e18)
Change-Id: I267ef6fa155ff15d6ebfc76dc1abafd9aa1f44df
Reviewed-on: http://git-master/r/1227923
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
|
|
|
Implement a bitmap allocator for GPU use. This allocator is useful for
managing memory (or resource) regions where the buddy allocator is not
ideal. Some instances are small regions or where the resource management
must not make calls to the kernel's memory allocation routines (anything
that ultimately calls alloc_page()).
The code path where this avoidance of alloc_page() is most required is
the gpfifo submit path. In order to keep this routine fast and have
predicable time constraints no alloc_page() calls is necessary. The
buddy allocator does not work for this since every time a buddy is
allocated there is the possibility that a pair (or more) buddy structs
have to be made. These allocs could perhaps require a call into
alloc_page() if there is not enouch space in the kmem_cache slab for
the buddy structs.
Change-Id: Ia46fce62d4bdafcebbc153b21b515cb51641d241
Signed-off-by: Alex Waterman <alexw@nvidia.com>
Reviewed-on: http://git-master/r/1176446
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
|
