[PATCH] drm/mm: add ig_frag selftest

[Nirmoy]

On 5/28/20 6:04 PM, Chris Wilson wrote:
> Quoting Nirmoy Das (2020-05-28 14:05:56)
>> This patch introduces fragmentation in the address range
>> and measures time taken by 10k insertions for each modes.
>>
>> ig_frag() will fail if one of the mode takes more than 1 sec.
>>
>> Output:
>> <snip>
>> [   37.326723] drm_mm: igt_sanitycheck - ok!
>> [   37.326727] igt_debug 0x0000000000000000-0x0000000000000200: 512: free
>> [   37.326728] igt_debug 0x0000000000000200-0x0000000000000600: 1024: used
>> [   37.326728] igt_debug 0x0000000000000600-0x0000000000000a00: 1024: free
>> [   37.326729] igt_debug 0x0000000000000a00-0x0000000000000e00: 1024: used
>> [   37.326730] igt_debug 0x0000000000000e00-0x0000000000001000: 512: free
>> [   37.326730] igt_debug total: 4096, used 2048 free 2048
>> [   56.040064] drm_mm: best fragmented insert took 504 msecs
>> [   56.082184] drm_mm: bottom-up fragmented insert took 40 msecs
>> [   56.102255] drm_mm: top-down fragmented insert took 20 msecs
>> [   56.107177] drm_mm: evict fragmented insert took 4 msecs
>> <snip>
>>
>> Signed-off-by: Nirmoy Das <nirmoy.das at amd.com>
>> ---
>>   drivers/gpu/drm/selftests/drm_mm_selftests.h |  1 +
>>   drivers/gpu/drm/selftests/test-drm_mm.c      | 59 ++++++++++++++++++++
>>   2 files changed, 60 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h b/drivers/gpu/drm/selftests/drm_mm_selftests.h
>> index 6b943ea1c57d..8c87c964176b 100644
>> --- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
>> +++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
>> @@ -14,6 +14,7 @@ selftest(insert, igt_insert)
>>   selftest(replace, igt_replace)
>>   selftest(insert_range, igt_insert_range)
>>   selftest(align, igt_align)
>> +selftest(frag, igt_frag)
>>   selftest(align32, igt_align32)
>>   selftest(align64, igt_align64)
>>   selftest(evict, igt_evict)
>> diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
>> index 9aabe82dcd3a..4c08ca86bb86 100644
>> --- a/drivers/gpu/drm/selftests/test-drm_mm.c
>> +++ b/drivers/gpu/drm/selftests/test-drm_mm.c
>> @@ -1033,6 +1033,65 @@ static int igt_insert_range(void *ignored)
>>          return 0;
>>   }
>>   
>> +static int igt_frag(void *ignored)
>> +{
>> +       const struct insert_mode *mode;
>> +       struct drm_mm mm;
>> +       struct drm_mm_node *nodes, *node, *next;
>> +       unsigned int size = 4096, align = 8192;
>> +       unsigned long start, timeout = 1000;
>> +       const unsigned int max_count = 10000;
>> +       unsigned int i;
>> +       int ret = -EINVAL;
>> +
>> +       /* For each of the possible insertion modes, we pass an size, alignment
>> +        * value that is known to introduce fragmentation and check that it
>> +        * doesn't take more than 1 sec.
>> +        */
>> +
>> +       nodes = vzalloc(array_size(max_count, sizeof(*nodes)));
>> +       if (!nodes)
>> +               goto err;
>> +
>> +       drm_mm_init(&mm, 1, U64_MAX - 2);
>> +
>> +       for (mode = insert_modes; mode->name; mode++) {
>> +               start = jiffies;
>> +
>> +               for (i = 0; i < max_count; i++) {
>> +                       if (jiffies_to_msecs(jiffies - start) >= timeout) {
>> +                               pr_err("%s fragmented insert took more than %lu msecs\n",
>> +                                      mode->name, timeout);
>> +                               goto out;
> We will run into problems with fixed timeouts on slow devices (emulated
> virtual machines and whatnot). And yes there are a few that are known to
> run kernel selftests and send bug reports (and complain about slow
> tests such as the other drm_mm selftests :).


I had this in my mind but didn't think about emulated VMs :)


>
> Off the top of my head, we expect the fragmented search to scale
> [sub]linearly, whereas at the moment it's quadratic. How about if we do
> something like insert as many as we can within 50ms, and then verify
> that if we double that number of inserts it is less than 200ms. We will
> still run into fun with the CPU scheduler causing imprecise timing, but
> that should have sufficiently wide error margins.


This sounds like a good idea. I will send a v2 and cc to 
intel-gfx at lists.freedesktop.org as well.


Thanks,

Nirmoy


> -Chris
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cnirmoy.das%40amd.com%7Cfc9863e63ecf452884d908d80320d969%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637262786936101207&sdata=J%2Bpu1rYIsLv5KBpD89rTkU50w%2FABDcGCDWlMnutvy%2B4%3D&reserved=0