On 07/03/2022 14:37, Arunpravin wrote:
place BUG_ON(order < min_order) outside do..while loop as it fails Unigine Heaven benchmark.
Unigine Heaven has buffer allocation requests for example required pages are 161 and alignment request is 128. To allocate the remaining 33 pages, continues the iteration to find the order value which is 5 and when it compares with min_order = 7, enables the BUG_ON(). To avoid this problem, placed the BUG_ON check outside of do..while loop.
Signed-off-by: Arunpravin Arunpravin.PaneerSelvam@amd.com
drivers/gpu/drm/drm_buddy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index 72f52f293249..ed94c56b720f 100644 --- a/drivers/gpu/drm/drm_buddy.c +++ b/drivers/gpu/drm/drm_buddy.c @@ -669,10 +669,11 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm, order = fls(pages) - 1; min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);
- BUG_ON(order < min_order);
Isn't the issue that we are allowing a size that is not aligned to the requested min_page_size? Should we not fix the caller(and throw a normal error here), or perhaps add the round_up() here instead?
i.e if someone does:
alloc_blocks(mm, 0, end, 4096, 1<<16, &blocks, flags);
This will still trigger the BUG_ON() even if we move it out of the loop, AFAICT.
- do { order = min(order, (unsigned int)fls(pages) - 1); BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);do { if (flags & DRM_BUDDY_RANGE_ALLOCATION)
base-commit: 8025c79350b90e5a8029234d433578f12abbae2b