Re: [PATCH v5 2/2] gpu/tests/buddy: add dirty tracker performance KUnit test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Resource exhaustion (OOM) due to massive allocation loop in KUnit test
--

--- Patch [2]: [PATCH v5 2/2] gpu/tests/buddy: add dirty tracker performance KUnit test ---
commit 227b33731ff64ce8294c937aa003f6e17a7481ed
Author: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>

gpu/tests/buddy: add dirty tracker performance KUnit test

This commit adds a new KUnit test to demonstrate the performance advantage of the decoupled dirty-tracker design. The test runs two scenarios on a 4 GiB pool with 4 KiB allocations to evaluate contiguous and repeated allocation latency.

> diff --git a/drivers/gpu/tests/gpu_buddy_test.c b/drivers/gpu/tests/gpu_buddy_test.c
> index e31f368ada951..e37505849ecc7 100644
> --- a/drivers/gpu/tests/gpu_buddy_test.c
> +++ b/drivers/gpu/tests/gpu_buddy_test.c
[ ... ]
> +static void gpu_test_buddy_dirty_tracker_performance(struct kunit *test)
> +{
[ ... ]
> +	KUNIT_ASSERT_FALSE_MSG(test, gpu_buddy_init(&mm, SZ_4G, SZ_4K),
> +			       "buddy_init failed\n");
> +
> +	for (i = 0; i < SZ_4G / SZ_4K; i++)
> +		KUNIT_ASSERT_FALSE_MSG(test,
> +				       gpu_buddy_alloc_blocks(&mm, 0, SZ_4G, SZ_4K, SZ_4K,
> +							      &allocated, 0),
> +				       "buddy_alloc hit an error size=%u\n", SZ_4K);

[Severity: Medium]
Could this loop cause an Out-Of-Memory (OOM) regression in constrained KUnit
environments?

Since the test fragments a 4 GiB pool into 4 KiB chunks, this loop executes
1,048,576 times. The allocator will create nearly 2 million struct
gpu_buddy_block metadata nodes, which can consume around 192 MB of kernel slab
memory (and significantly more with KASAN enabled). 

KUnit tests often run in restricted environments like UML with 128-256 MB of
RAM, so this might reliably trigger an OOM panic and break the test suite.

Could a smaller pool size be used to demonstrate the performance difference
without consuming as much kernel memory?

[ ... ]
> +	/*
> +	 * Repeated alloc throughput from a maximally fragmented pool
[ ... ]
> +	KUNIT_ASSERT_FALSE_MSG(test, gpu_buddy_init(&mm, SZ_4G, SZ_4K),
> +			       "buddy_init failed\n");
> +
> +	for (i = 0; i < SZ_4G / SZ_4K; i++)
> +		KUNIT_ASSERT_FALSE_MSG(test,
> +				       gpu_buddy_alloc_blocks(&mm, 0, SZ_4G, SZ_4K, SZ_4K,
> +							      &allocated, 0),
> +				       "buddy_alloc hit an error size=%u\n", SZ_4K);

[Severity: Medium]
The same massive allocation loop is repeated for the second scenario here.
Does this need to be scaled down as well to avoid exhausting memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707141238.711499-1-Arunpravin.PaneerSelvam@amd.com?part=2