[Intel-gfx] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper

[Intel-gfx] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper

[Chris Wilson]

While the test is blocked, we keep trying the gen12_single_ctx_helper().
As this is using the parent's drm_fd, all of our context allocations are
persistent. Reopen the device in the child so that when we exit, our
allocations are freed along with the process -- avoiding a total memory
leak if the test is stuck.

This does not explain why the test was stuck, it just prevents us from
exacerbating the error condition. Hopefully leaving the system in a more
debuggable state.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/2126
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
 tests/i915/perf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/i915/perf.c b/tests/i915/perf.c
index d4ebae30d..dbf7e3497 100644
--- a/tests/i915/perf.c
+++ b/tests/i915/perf.c
@@ -3845,6 +3845,7 @@ static void gen12_single_ctx_helper(void)
 		.format = test_set->perf_oa_format
 	};
 
+	drm_fd = gem_reopen_driver(drm_fd);
 	bufmgr = drm_intel_bufmgr_gem_init(drm_fd, 4096);
 	drm_intel_bufmgr_gem_enable_reuse(bufmgr);
 
@@ -4107,6 +4108,7 @@ static void gen12_single_ctx_helper(void)
 	drm_intel_gem_context_destroy(context1);
 	drm_intel_bufmgr_destroy(bufmgr);
 	__perf_close(stream_fd);
+	close(drm_fd);
 }
 
 static void
-- 
2.27.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper

[Lionel Landwerlin]

Could be a particularly slow PIPE_CONTROL instruction on TGL.
We assumed that in a sequence of instructions : PC0, MI_RPC0, PC1, MI_RPC1

The delta of time PC1 - PC0 would be with 500ns of MI_RPC1 - MI_RPC0.
That does sound a bit broken tbf...

Patch looks good :

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Thanks,

-Lionel

On 02/07/2020 15:39, Chris Wilson wrote:
> While the test is blocked, we keep trying the gen12_single_ctx_helper().
> As this is using the parent's drm_fd, all of our context allocations are
> persistent. Reopen the device in the child so that when we exit, our
> allocations are freed along with the process -- avoiding a total memory
> leak if the test is stuck.
>
> This does not explain why the test was stuck, it just prevents us from
> exacerbating the error condition. Hopefully leaving the system in a more
> debuggable state.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/2126
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> ---
>   tests/i915/perf.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/tests/i915/perf.c b/tests/i915/perf.c
> index d4ebae30d..dbf7e3497 100644
> --- a/tests/i915/perf.c
> +++ b/tests/i915/perf.c
> @@ -3845,6 +3845,7 @@ static void gen12_single_ctx_helper(void)
>   		.format = test_set->perf_oa_format
>   	};
>   
> +	drm_fd = gem_reopen_driver(drm_fd);
>   	bufmgr = drm_intel_bufmgr_gem_init(drm_fd, 4096);
>   	drm_intel_bufmgr_gem_enable_reuse(bufmgr);
>   
> @@ -4107,6 +4108,7 @@ static void gen12_single_ctx_helper(void)
>   	drm_intel_gem_context_destroy(context1);
>   	drm_intel_bufmgr_destroy(bufmgr);
>   	__perf_close(stream_fd);
> +	close(drm_fd);
>   }
>   
>   static void


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] i915/perf: Instantiate a local drm_fd for the unprivileged helper

[Chris Wilson]

While the test is blocked, we keep trying the gen12_single_ctx_helper().
As this is using the parent's drm_fd, all of our context allocations are
persistent. Reopen the device in the child so that when we exit, our
allocations are freed along with the process -- avoiding a total memory
leak if the test is stuck.

This does not explain why the test was stuck, it just prevents us from
exacerbating the error condition. Hopefully leaving the system in a more
debuggable state.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/2126
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
 tests/i915/perf.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tests/i915/perf.c b/tests/i915/perf.c
index d4ebae30d..92edc9f1f 100644
--- a/tests/i915/perf.c
+++ b/tests/i915/perf.c
@@ -4120,8 +4120,13 @@ gen12_test_single_ctx_render_target_writes_a_counter(void)
 
 	do {
 		igt_fork_helper(&child) {
+			/* A local device for local resources. */
+			drm_fd = gem_reopen_driver(drm_fd);
+
 			igt_drop_root();
 			gen12_single_ctx_helper();
+
+			close(drm_fd);
 		}
 		child_ret = igt_wait_helper(&child);
 		igt_assert(WEXITSTATUS(child_ret) == EAGAIN ||
-- 
2.27.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx