From 641444188f18dbf56dda980e31f1b404dbb6f166 Mon Sep 17 00:00:00 2001 From: Alex Waterman Date: Mon, 22 Aug 2016 11:19:50 -0700 Subject: gpu: nvgpu: bitmap allocator optimization 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 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 --- drivers/gpu/nvgpu/gk20a/bitmap_allocator_priv.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'drivers/gpu/nvgpu/gk20a/bitmap_allocator_priv.h') diff --git a/drivers/gpu/nvgpu/gk20a/bitmap_allocator_priv.h b/drivers/gpu/nvgpu/gk20a/bitmap_allocator_priv.h index 053a6425..a686b704 100644 --- a/drivers/gpu/nvgpu/gk20a/bitmap_allocator_priv.h +++ b/drivers/gpu/nvgpu/gk20a/bitmap_allocator_priv.h @@ -31,6 +31,15 @@ struct gk20a_bitmap_allocator { u64 num_bits; /* Number of allocatable bits. */ u64 bit_offs; /* Offset of bitmap. */ + /* + * Optimization for making repeated allocations faster. Keep track of + * the next bit after the most recent allocation. This is where the next + * search will start from. This should make allocation faster in cases + * where lots of allocations get made one after another. It shouldn't + * have a negative impact on the case where the allocator is fragmented. + */ + u64 next_blk; + unsigned long *bitmap; /* The actual bitmap! */ struct rb_root allocs; /* Tree of outstanding allocations. */ -- cgit v1.2.2