Re: [PATCH] drm/mm: add ig_frag selftest

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxx>
---
  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@xxxxxxxxxxxxxxxxxxxxx as well.


Thanks,

Nirmoy


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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux