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&data=02%7C01%7Cnirmoy.das%40amd.com%7Cfc9863e63ecf452884d908d80320d969%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637262786936101207&sdata=J%2Bpu1rYIsLv5KBpD89rTkU50w%2FABDcGCDWlMnutvy%2B4%3D&reserved=0
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
