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 <[email protected]>

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/[email protected]?part=2

Reply via email to