I have just gathered real data on this and the result is surprising. Viewperf 13, Viewperf 2020, Unigine benchmarks, and others have been used to gather BO list data.
The maximum number of BOs that has been observed in the CS ioctl for radeonsi is 283, even though the actual number of OpenGL BOs can be on the order of 50k. That's thanks to the slab allocator in the Mesa amdgpu winsys. RADV uses VM_ALWAYS_VALID by default currently. radeonsi could also start using it if the kernel memory management behaves optimally. Old Mesa drivers might use more BOs, especially RADV which doesn't have a slab allocator. Some limit may also be needed for lists of sync objects in all our ioctls and all arrays in general. Marek On Thu, Mar 12, 2026 at 1:59 PM Christian König <[email protected]> wrote: > > On 3/12/26 18:44, Alex Deucher wrote: > > + Marek, > > > > This was the feedback from Marek the last time this was brought up: > > > > "USHRT_MAX seems too low. Traces for workstation apps create 20-30k > > BOs, which is not very far from the limit. RADV doesn't suballocate > > BOs. Neither GL nor VK has a ilmit on the number of BOs that can be > > created. The hypothetical maximum number of BOs that can be allocated > > on a GPU with 32GB of addressable memory is 8 million." > > > > Does 128K sound more reasonable? > > I think so, yes. Event 64k seems reasonable large to me considering that only > BOs which are not per VM need to be in the list. > > E.g. RADV barely uses this feature as far as I know. > > Regards, > Christian. > > > > > Alex > > On Thu, Mar 12, 2026 at 6:13 AM Jesse.Zhang <[email protected]> wrote: > >> > >> Userspace can pass an arbitrary number of BO list entries via the > >> bo_number field. Although the previous multiplication overflow check > >> prevents out-of-bounds allocation, a large number of entries could still > >> cause excessive memory allocation (up to potentially gigabytes) and > >> unnecessarily long list processing times. > >> > >> Introduce a hard limit of 128k entries per BO list, which is more than > >> sufficient for any realistic use case (e.g., a single list containing all > >> buffers in a large scene). This prevents memory exhaustion attacks and > >> ensures predictable performance. > >> > >> Return -EINVAL if the requested entry count exceeds the limit > >> > >> Suggested-by: Christian König <[email protected]> > >> Signed-off-by: Jesse Zhang <[email protected]> > >> --- > >> drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c > >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c > >> index 87ec46c56a6e..3270ea50bdc7 100644 > >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c > >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c > >> @@ -36,6 +36,7 @@ > >> > >> #define AMDGPU_BO_LIST_MAX_PRIORITY 32u > >> #define AMDGPU_BO_LIST_NUM_BUCKETS (AMDGPU_BO_LIST_MAX_PRIORITY + 1) > >> +#define AMDGPU_BO_LIST_MAX_ENTRIES (128 * 1024) > >> > >> static void amdgpu_bo_list_free_rcu(struct rcu_head *rcu) > >> { > >> @@ -188,6 +189,9 @@ int amdgpu_bo_create_list_entry_array(struct > >> drm_amdgpu_bo_list_in *in, > >> const uint32_t bo_number = in->bo_number; > >> struct drm_amdgpu_bo_list_entry *info; > >> > >> + if (bo_number > AMDGPU_BO_LIST_MAX_ENTRIES) > >> + return -EINVAL; > >> + > >> /* copy the handle array from userspace to a kernel buffer */ > >> if (likely(info_size == bo_info_size)) { > >> info = vmemdup_array_user(uptr, bo_number, info_size); > >> -- > >> 2.49.0 > >> >
