[igt-dev] [PATCH 0/6] Add igt tests for perf OA interrupts

[igt-dev] [PATCH 0/6] Add igt tests for perf OA interrupts

[Umesh Nerlige Ramappa]

Tests to verify interrupt support in perf OA

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>

Lionel Landwerlin (4):
  include/drm-uapi: Update i915_drm.h for perf OA APIs
  tests/perf: new tests for parameterized OA buffer polling
  tests/perf: new tests for OA interrupt
  tests/perf: add flush data ioctl test

Umesh Nerlige Ramappa (2):
  test/perf: Drop caches when closing perf stream
  tools: Enable interrupt support in i915 perf recorder

 include/drm-uapi/i915_drm.h          |  41 +++
 tests/perf.c                         | 481 +++++++++++++++++++++++++--
 tools/i915-perf/i915_perf_recorder.c |  53 ++-
 3 files changed, 537 insertions(+), 38 deletions(-)

-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Umesh Nerlige Ramappa]

Running ./build/tests/perf will run all the perf subtests in a sequence.
When running tests in a sequence, subsequent tests may not run with a
clean slate. For resources that are lazily released, drop caches in
__perf_close.

Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
---
 tests/perf.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tests/perf.c b/tests/perf.c
index 5e818030..189c6aa1 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -244,6 +244,12 @@ __perf_close(int fd)
 		close(pm_fd);
 		pm_fd = -1;
 	}
+
+	/* When running tests in a sequence, subsequent tests may not run with a
+	 * clean slate. For resources that are lazily released, cleanup here.
+	 */
+	if (drm_fd >= 0 && !getgid() && !getuid())
+		gem_quiescent_gpu(drm_fd);
 }
 
 static int
@@ -3993,7 +3999,6 @@ test_rc6_disable(void)
 	igt_assert_eq(n_events_end - n_events_start, 0);
 
 	__perf_close(stream_fd);
-	gem_quiescent_gpu(drm_fd);
 
 	n_events_start = rc6_residency_ms();
 	nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, NULL);
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 2/6] include/drm-uapi: Update i915_drm.h for perf OA APIs

[Umesh Nerlige Ramappa]

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Add APIs to enable/disable interrupts in perf OA.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
---
 include/drm-uapi/i915_drm.h | 41 +++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index 3794e768..fca6ab4d 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -1969,6 +1969,26 @@ enum drm_i915_perf_property_id {
 	 */
 	DRM_I915_PERF_PROP_HOLD_PREEMPTION,
 
+	/**
+	 * Specifying this property sets up a hrtimer in nanoseconds at which
+	 * the i915 driver will check the OA buffer for available data. A
+	 * value of 0 means no hrtimer will be started. Values below 100
+	 * microseconds are not allowed.
+	 *
+	 * This property is available in perf revision 4.
+	 */
+	DRM_I915_PERF_PROP_POLL_OA_DELAY,
+
+	/**
+	 * Specifying this property sets up the interrupt mechanism for the OA
+	 * buffer in i915. This option in conjuction with a long polling delay
+	 * for avaibility of OA data can reduce CPU load significantly if you
+	 * do not care about OA data being read as soon as it's available.
+	 *
+	 * This property is available in perf revision 5.
+	 */
+	DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT,
+
 	DRM_I915_PERF_PROP_MAX /* non-ABI */
 };
 
@@ -2024,6 +2044,27 @@ struct drm_i915_perf_open_param {
  */
 #define I915_PERF_IOCTL_CONFIG	_IO('i', 0x2)
 
+/**
+ * Actively check the availability of data from a stream.
+ *
+ * A stream data availability can be driven by two types of events :
+ *
+ *   - if enabled, the kernel's hrtimer checking the amount of available data
+ *     in the OA buffer through head/tail registers.
+ *
+ *   - if enabled, the OA unit's interrupt mechanism
+ *
+ * The kernel hrtimer incur a cost of running callback at fixed time
+ * intervals, while the OA interrupt might only happen rarely. In the
+ * situation where the application has disabled the kernel's hrtimer and only
+ * uses the OA interrupt to know about available data, the application can
+ * request an active check of the available OA data through this ioctl. This
+ * will make any data in the OA buffer available with either poll() or read().
+ *
+ * This ioctl is available in perf revision 6.
+ */
+#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x3)
+
 /**
  * Common to all i915 perf records
  */
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 3/6] tests/perf: new tests for parameterized OA buffer polling

[Umesh Nerlige Ramappa]

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

2 new tests verifying that the OA buffer is properly checked at the
frequency specified by userspace.

v2: (Umesh)
- Capture start_times in test_polling
- Second parameterized test used a 500us hrtimer. Occassionally, this
  timing does not fall within the duration/100 requirement for the time
  spent in kernel. Change this value to 2ms to accommodate all
  platforms.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
---
 tests/perf.c | 136 ++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 102 insertions(+), 34 deletions(-)

diff --git a/tests/perf.c b/tests/perf.c
index 189c6aa1..37dc1db1 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -234,6 +234,24 @@ get_oa_format(enum drm_i915_oa_format format)
 		return gen8_oa_formats[format];
 }
 
+static char *
+pretty_print_oa_period(uint64_t oa_period_ns)
+{
+	static char result[100];
+	static const char *units[4] = { "ns", "us", "ms", "s" };
+	double val = oa_period_ns;
+	int iter = 0;
+
+	while (iter < (ARRAY_SIZE(units) - 1) &&
+	       val >= 1000.0f) {
+		val /= 1000.0f;
+		iter++;
+	}
+
+	snprintf(result, sizeof(result), "%.3f%s", val, units[iter]);
+	return result;
+}
+
 static void
 __perf_close(int fd)
 {
@@ -1927,15 +1945,9 @@ get_time(void)
  * kernelspace.
  */
 static void
-test_blocking(void)
+test_blocking(uint64_t requested_oa_period, bool set_kernel_hrtimer, uint64_t kernel_hrtimer)
 {
-	/* ~40 milliseconds
-	 *
-	 * Having a period somewhat > sysconf(_SC_CLK_TCK) helps to stop
-	 * scheduling (liable to kick in when we make blocking poll()s/reads)
-	 * from interfering with the test.
-	 */
-	int oa_exponent = max_oa_exponent_for_period_lte(40000000);
+	int oa_exponent = max_oa_exponent_for_period_lte(requested_oa_period);
 	uint64_t oa_period = oa_exponent_to_ns(oa_exponent);
 	uint64_t properties[] = {
 		/* Include OA reports in samples */
@@ -1945,11 +1957,16 @@ test_blocking(void)
 		DRM_I915_PERF_PROP_OA_METRICS_SET, test_set->perf_oa_metrics_set,
 		DRM_I915_PERF_PROP_OA_FORMAT, test_set->perf_oa_format,
 		DRM_I915_PERF_PROP_OA_EXPONENT, oa_exponent,
+
+		/* Kernel configuration (optional) */
+		DRM_I915_PERF_PROP_POLL_OA_DELAY, kernel_hrtimer,
 	};
 	struct drm_i915_perf_open_param param = {
 		.flags = I915_PERF_FLAG_FD_CLOEXEC |
 			I915_PERF_FLAG_DISABLED,
-		.num_properties = sizeof(properties) / 16,
+		.num_properties = (set_kernel_hrtimer ?
+				   (ARRAY_SIZE(properties) / 2) :
+				   ((ARRAY_SIZE(properties) / 2) - 1)),
 		.properties_ptr = to_user_pointer(properties),
 	};
 	uint8_t buf[1024 * 1024];
@@ -1971,7 +1988,7 @@ test_blocking(void)
 	 * the knowledge that that the driver uses a 200Hz hrtimer (5ms period)
 	 * to check for data and giving some time to read().
 	 */
-	int min_iterations = (test_duration_ns / (oa_period + 6000000ull));
+	int min_iterations = (test_duration_ns / (oa_period + kernel_hrtimer + kernel_hrtimer / 5));
 
 	int64_t start, end;
 	int n = 0;
@@ -1981,9 +1998,10 @@ test_blocking(void)
 	times(&start_times);
 
 	igt_debug("tick length = %dns, test duration = %"PRIu64"ns, min iter. = %d,"
-		  " estimated max iter. = %d, oa_period = %"PRIu64"ns\n",
+		  " estimated max iter. = %d, oa_period = %s\n",
 		  (int)tick_ns, test_duration_ns,
-		  min_iterations, max_iterations, oa_period);
+		  min_iterations, max_iterations,
+		  pretty_print_oa_period(oa_period));
 
 	/* In the loop we perform blocking polls while the HW is sampling at
 	 * ~25Hz, with the expectation that we spend most of our time blocked
@@ -2085,15 +2103,9 @@ test_blocking(void)
 }
 
 static void
-test_polling(void)
+test_polling(uint64_t requested_oa_period, bool set_kernel_hrtimer, uint64_t kernel_hrtimer)
 {
-	/* ~40 milliseconds
-	 *
-	 * Having a period somewhat > sysconf(_SC_CLK_TCK) helps to stop
-	 * scheduling (liable to kick in when we make blocking poll()s/reads)
-	 * from interfering with the test.
-	 */
-	int oa_exponent = max_oa_exponent_for_period_lte(40000000);
+	int oa_exponent = max_oa_exponent_for_period_lte(requested_oa_period);
 	uint64_t oa_period = oa_exponent_to_ns(oa_exponent);
 	uint64_t properties[] = {
 		/* Include OA reports in samples */
@@ -2103,12 +2115,17 @@ test_polling(void)
 		DRM_I915_PERF_PROP_OA_METRICS_SET, test_set->perf_oa_metrics_set,
 		DRM_I915_PERF_PROP_OA_FORMAT, test_set->perf_oa_format,
 		DRM_I915_PERF_PROP_OA_EXPONENT, oa_exponent,
+
+		/* Kernel configuration (optional) */
+		DRM_I915_PERF_PROP_POLL_OA_DELAY, kernel_hrtimer,
 	};
 	struct drm_i915_perf_open_param param = {
 		.flags = I915_PERF_FLAG_FD_CLOEXEC |
 			I915_PERF_FLAG_DISABLED |
 			I915_PERF_FLAG_FD_NONBLOCK,
-		.num_properties = sizeof(properties) / 16,
+		.num_properties = (set_kernel_hrtimer ?
+				   (ARRAY_SIZE(properties) / 2) :
+				   ((ARRAY_SIZE(properties) / 2) - 1)),
 		.properties_ptr = to_user_pointer(properties),
 	};
 	uint8_t buf[1024 * 1024];
@@ -2122,15 +2139,16 @@ test_polling(void)
 	int n_extra_iterations = 0;
 
 	/* It's a bit tricky to put a lower limit here, but we expect a
-	 * relatively low latency for seeing reports, while we don't currently
-	 * give any control over this in the api.
+	 * relatively low latency for seeing reports.
 	 *
-	 * We assume a maximum latency of 6 millisecond to deliver a POLLIN and
-	 * read() after a new sample is written (46ms per iteration) considering
-	 * the knowledge that that the driver uses a 200Hz hrtimer (5ms period)
-	 * to check for data and giving some time to read().
+	 * We assume a maximum latency of kernel_hrtimer + some margin
+	 * to deliver a POLLIN and read() after a new sample is
+	 * written (40ms + hrtimer + margin per iteration) considering
+	 * the knowledge that that the driver uses a 200Hz hrtimer
+	 * (5ms period) to check for data and giving some time to
+	 * read().
 	 */
-	int min_iterations = (test_duration_ns / (oa_period + 6000000ull));
+	int min_iterations = (test_duration_ns / (oa_period + (kernel_hrtimer + kernel_hrtimer / 5)));
 	int64_t start, end;
 	int n = 0;
 
@@ -2138,8 +2156,9 @@ test_polling(void)
 
 	times(&start_times);
 
-	igt_debug("tick length = %dns, test duration = %"PRIu64"ns, min iter. = %d, max iter. = %d\n",
-		  (int)tick_ns, test_duration_ns,
+	igt_debug("tick length = %dns, oa period = %s, "
+		  "test duration = %"PRIu64"ns, min iter. = %d, max iter. = %d\n",
+		  (int)tick_ns, pretty_print_oa_period(oa_period), test_duration_ns,
 		  min_iterations, max_iterations);
 
 	/* In the loop we perform blocking polls while the HW is sampling at
@@ -4507,6 +4526,23 @@ test_sysctl_defaults(void)
 	igt_assert_eq(max_freq, 100000);
 }
 
+static int i915_perf_revision(int fd)
+{
+	drm_i915_getparam_t gp;
+	int value = 1, ret;
+
+	gp.param = I915_PARAM_PERF_REVISION;
+	gp.value = &value;
+	ret = igt_ioctl(drm_fd, DRM_IOCTL_I915_GETPARAM, &gp);
+	if (ret == -1) {
+		/* If the param is missing, consider version 1. */
+		igt_assert_eq(errno, EINVAL);
+		return 1;
+	}
+
+	return value;
+}
+
 igt_main
 {
 	igt_fixture {
@@ -4589,11 +4625,43 @@ igt_main
 	igt_subtest("enable-disable")
 		test_enable_disable();
 
-	igt_subtest("blocking")
-		test_blocking();
+	igt_describe("Test blocking read with default hrtimer frequency");
+	igt_subtest("blocking") {
+		test_blocking(40 * 1000 * 1000 /* 40ms oa period */,
+			      false /* set_kernel_hrtimer */,
+			      5 * 1000 * 1000 /* default 5ms/200Hz hrtimer */);
+	}
+
+	igt_describe("Test blocking read with different hrtimer frequencies");
+	igt_subtest("blocking-parameterized") {
+		igt_require(i915_perf_revision(drm_fd) >= 4);
+
+		test_blocking(10 * 1000 * 1000 /* 10ms oa period */,
+			      true /* set_kernel_hrtimer */,
+			      40 * 1000 * 1000 /* default 40ms hrtimer */);
+		test_blocking(500 * 1000 /* 500us oa period */,
+			      true /* set_kernel_hrtimer */,
+			      2 * 1000 * 1000 /* default 2ms hrtimer */);
+	}
 
-	igt_subtest("polling")
-		test_polling();
+	igt_describe("Test polled read with default hrtimer frequency");
+	igt_subtest("polling") {
+		test_polling(40 * 1000 * 1000 /* 40ms oa period */,
+			     false /* set_kernel_hrtimer */,
+			     5 * 1000 * 1000 /* default 5ms/200Hz hrtimer */);
+	}
+
+	igt_describe("Test polled read with different hrtimer frequencies");
+	igt_subtest("polling-parameterized") {
+		igt_require(i915_perf_revision(drm_fd) >= 4);
+
+		test_polling(10 * 1000 * 1000 /* 10ms oa period */,
+			     true /* set_kernel_hrtimer */,
+			     40 * 1000 * 1000 /* default 40ms hrtimer */);
+		test_polling(500 * 1000 /* 500us oa period */,
+			     true /* set_kernel_hrtimer */,
+			     2 * 1000 * 1000 /* default 2ms hrtimer */);
+	}
 
 	igt_subtest("short-reads")
 		test_short_reads();
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 4/6] tests/perf: new tests for OA interrupt

[Umesh Nerlige Ramappa]

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Those tests verify that the interrupt wakes up userspace waiting on
the perf stream either with poll() or with read().

v2: (Umesh)
- read() will check for reports in OA buffer prior to blocking for new
  reports. This results in occassional 1 or 2 reports being returned in
  the read call instead of the number of reports that the test is
  expecting. Since read behaves as expected, the only way for us to
  block is to call poll prior to read.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
 tests/perf.c | 208 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 208 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index 37dc1db1..8a64c559 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -456,6 +456,20 @@ oa_exponent_to_ns(int exponent)
        return 1000000000ULL * (2ULL << exponent) / intel_perf->devinfo.timestamp_frequency;
 }
 
+static int
+find_oa_exponent_for_buffer_fill_time(size_t oa_buf_size, size_t report_size, uint64_t fill_time_ns)
+{
+       size_t n_reports = oa_buf_size / report_size;
+
+       for (int e = 1; e < 32; e++) {
+               if (fill_time_ns < oa_exponent_to_ns(e) * n_reports)
+                       return e;
+       }
+
+       igt_assert(!"reached");
+       return -1;
+}
+
 static bool
 oa_report_is_periodic(uint32_t oa_exponent, const uint32_t *report)
 {
@@ -2290,6 +2304,109 @@ test_polling(uint64_t requested_oa_period, bool set_kernel_hrtimer, uint64_t ker
 	__perf_close(stream_fd);
 }
 
+static void
+test_interrupt(uint64_t oa_exponent,
+	       uint64_t kernel_oa_poll_delay,
+	       bool use_interrupt,
+	       bool expect_buffer_lost,
+	       bool use_polling,
+	       uint32_t expect_min_reports)
+{
+	uint64_t properties[] = {
+		/* Include OA reports in samples */
+		DRM_I915_PERF_PROP_SAMPLE_OA, true,
+
+		/* OA unit configuration */
+		DRM_I915_PERF_PROP_OA_METRICS_SET, test_set->perf_oa_metrics_set,
+		DRM_I915_PERF_PROP_OA_FORMAT, test_set->perf_oa_format,
+		DRM_I915_PERF_PROP_OA_EXPONENT, oa_exponent,
+		DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT, use_interrupt,
+
+		/* Kernel configuration */
+		DRM_I915_PERF_PROP_POLL_OA_DELAY, kernel_oa_poll_delay,
+	};
+	struct drm_i915_perf_open_param param = {
+		.flags = I915_PERF_FLAG_FD_CLOEXEC |
+			I915_PERF_FLAG_DISABLED |
+			(use_polling ? I915_PERF_FLAG_FD_NONBLOCK : 0),
+		.num_properties = ARRAY_SIZE(properties) / 2,
+		.properties_ptr = to_user_pointer(properties),
+	};
+	struct pollfd pollfd = { .events = POLLIN };
+	struct drm_i915_perf_record_header *header;
+	uint32_t n_reports = 0;
+	bool buffer_lost = false;
+	uint8_t *buf = malloc(MAX_OA_BUF_SIZE);
+	int ret;
+
+	stream_fd = __perf_open(drm_fd, &param, true /* prevent_pm */);
+	pollfd.fd = stream_fd;
+
+	igt_debug("OA period = %s, ",
+		  pretty_print_oa_period(oa_exponent_to_ns(oa_exponent)));
+	igt_debug("OA poll delay = %s, use interrupt = %i, "
+		  "expected min report = %u\n",
+		  pretty_print_oa_period(kernel_oa_poll_delay),
+		  use_interrupt, expect_min_reports);
+
+	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
+
+	while ((ret = poll(&pollfd, 1, -1)) < 0 &&
+	       errno == EINTR)
+		;
+	igt_assert_eq(ret, 1);
+	igt_assert(pollfd.revents & POLLIN);
+
+	while ((ret = read(stream_fd, buf, MAX_OA_BUF_SIZE)) < 0 &&
+	       errno == EINTR)
+		;
+
+	if (ret < 0)
+		igt_debug("Unexpected error when reading after poll = %d\n", errno);
+	igt_assert_neq(ret, -1);
+
+	__perf_close(stream_fd);
+
+	/* For Haswell reports don't contain a well defined reason
+	 * field we so assume all reports to be 'periodic'. For gen8+
+	 * we want to to consider that the HW automatically writes some
+	 * non periodic reports (e.g. on context switch) which might
+	 * lead to more successful read()s than expected due to
+	 * periodic sampling and we don't want these extra reads to
+	 * cause the test to fail...
+	 */
+	for (int offset = 0; offset < ret; offset += header->size) {
+		header = (void *)(buf + offset);
+
+		switch (header->type) {
+		case DRM_I915_PERF_RECORD_SAMPLE:
+			n_reports++;
+			break;
+		case DRM_I915_PERF_RECORD_OA_BUFFER_LOST:
+			buffer_lost = true;
+			break;
+		}
+	}
+
+	igt_debug("Got %i report(s)\n", n_reports);
+
+	igt_assert_eq(buffer_lost, expect_buffer_lost);
+
+	/*
+	 * Leave a 5% error margin for 2 reasons :
+	 *
+	 * - the tail pointer race condition might remove a couple of
+	 *   reports because things have not yet landed in memory.
+	 *
+	 * - the OA unit sometimes drop a writing a report here and
+	 *   there, the algorithm is linked to pressure on memory
+	 *   controller but undocumented.
+	 */
+	igt_assert_lte(expect_min_reports * 0.95, n_reports);
+
+	free(buf);
+}
+
 static void
 test_buffer_fill(void)
 {
@@ -4644,6 +4761,52 @@ igt_main
 			      2 * 1000 * 1000 /* default 2ms hrtimer */);
 	}
 
+	igt_describe("Test blocking read with interrupt and different hrtimer frequencies");
+	igt_subtest("blocking-with-interrupt") {
+		uint64_t target_fill_time = /* 1000ms */ 1000 * 1000 * 1000ul;
+		size_t report_size = get_oa_format(test_set->perf_oa_format).size;
+		uint32_t max_reports = MAX_OA_BUF_SIZE / report_size;
+		int oa_exponent =
+			find_oa_exponent_for_buffer_fill_time(MAX_OA_BUF_SIZE,
+							      report_size, target_fill_time);
+		uint64_t fill_time = oa_exponent_to_ns(oa_exponent) *
+			(MAX_OA_BUF_SIZE / report_size);
+
+		igt_require(i915_perf_revision(drm_fd) >= 5);
+
+		/*
+		 * We should be waken up by the HR timer but too late,
+		 * so we'll loose reports.
+		 */
+		test_interrupt(oa_exponent,
+			       fill_time + fill_time / 2,
+			       false /* interrupt */, true /* loss */, false /* use_polling */,
+			       0);
+
+		/*
+		 * We should get woken up by the HR timer and get the
+		 * appropriate number of report.
+		 */
+		test_interrupt(oa_exponent,
+			       /* 500us */ 500 * 1000,
+			       false /* interrupt */, false /* no loss */, false /* use_polling */,
+			       (500 * 1000 * max_reports) / fill_time);
+
+
+		/* We should be waken up by the interrupt first. */
+		test_interrupt(oa_exponent,
+			       2 * fill_time,
+			       true /* interrupt */, false /* no loss */, false /* use_polling */,
+			       max_reports / 2);
+
+		/* We should be waken up by the HR timer first. */
+		test_interrupt(oa_exponent,
+			       fill_time / 4,
+			       true /* interrupt */, false /* no loss */, false /* use_polling */,
+			       (fill_time / 4) * max_reports / fill_time);
+	}
+
+
 	igt_describe("Test polled read with default hrtimer frequency");
 	igt_subtest("polling") {
 		test_polling(40 * 1000 * 1000 /* 40ms oa period */,
@@ -4663,6 +4826,51 @@ igt_main
 			     2 * 1000 * 1000 /* default 2ms hrtimer */);
 	}
 
+	igt_describe("Test polled read with interrupt and different hrtimer frequencies");
+	igt_subtest("polling-with-interrupt") {
+		uint64_t target_fill_time = /* 1000ms */ 1000 * 1000 * 1000ul;
+		size_t report_size = get_oa_format(test_set->perf_oa_format).size;
+		uint32_t max_reports = MAX_OA_BUF_SIZE / report_size;
+		int oa_exponent =
+			find_oa_exponent_for_buffer_fill_time(MAX_OA_BUF_SIZE,
+							      report_size, target_fill_time);
+		uint64_t fill_time = oa_exponent_to_ns(oa_exponent) *
+			(MAX_OA_BUF_SIZE / report_size);
+
+		igt_require(i915_perf_revision(drm_fd) >= 5);
+
+		/*
+		 * We should be waken up by the HR timer but too late,
+		 * so we'll loose reports.
+		 */
+		test_interrupt(oa_exponent,
+			       fill_time + fill_time / 2,
+			       false /* interrupt */, true /* loss */, true /* use_polling */,
+			       0);
+
+		/*
+		 * We should get woken up by the HR timer and get the
+		 * appropriate number of report.
+		 */
+		test_interrupt(oa_exponent,
+			       /* 500us */ 500 * 1000,
+			       false /* interrupt */, false /* no loss */, true /* use_polling */,
+			       (500 * 1000 * max_reports) / fill_time);
+
+
+		/* We should be waken up by the interrupt first. */
+		test_interrupt(oa_exponent,
+			       2 * fill_time,
+			       true /* interrupt */, false /* no loss */, true /* use_polling */,
+			       max_reports / 2);
+
+		/* We should be waken up by the HR timer first. */
+		test_interrupt(oa_exponent,
+			       fill_time / 4,
+			       true /* interrupt */, false /* no loss */, true /* use_polling */,
+			       (fill_time / 4) * max_reports / fill_time);
+	}
+
 	igt_subtest("short-reads")
 		test_short_reads();
 
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 5/6] tests/perf: add flush data ioctl test

[Umesh Nerlige Ramappa]

From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Ensure we have proper behavior for the new I915_PERF_IOCTL_FLUSH_DATA.

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
 tests/perf.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 130 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index 8a64c559..890fe41f 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -4098,6 +4098,129 @@ gen12_test_single_ctx_render_target_writes_a_counter(void)
 	} while (WEXITSTATUS(child_ret) == EAGAIN);
 }
 
+/*
+ * Verifies that the I915_PERF_IOCTL_FLUSH_DATA ioctl forces the
+ * i915-perf driver to look at the available data in the OA buffer.
+ */
+static void
+test_flush_data(void)
+{
+	size_t report_size = get_oa_format(test_set->perf_oa_format).size;
+	int oa_exponent =
+		find_oa_exponent_for_buffer_fill_time(MAX_OA_BUF_SIZE,
+						      report_size,
+						      500 * 1000 * 1000 /* 500ms */);
+	uint64_t oa_period = oa_exponent_to_ns(oa_exponent);
+	size_t oa_buf_size = MAX_OA_BUF_SIZE;
+	int n_full_oa_reports = oa_buf_size / report_size;
+	uint64_t fill_duration = n_full_oa_reports * oa_period;
+	uint64_t properties[] = {
+		/* Include OA reports in samples */
+		DRM_I915_PERF_PROP_SAMPLE_OA, true,
+
+		/* OA unit configuration */
+		DRM_I915_PERF_PROP_OA_METRICS_SET, test_set->perf_oa_metrics_set,
+		DRM_I915_PERF_PROP_OA_FORMAT, test_set->perf_oa_format,
+		DRM_I915_PERF_PROP_OA_EXPONENT, oa_exponent,
+		DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT, true,
+
+		/* Kernel configuration */
+		DRM_I915_PERF_PROP_POLL_OA_DELAY, 0,
+	};
+	struct drm_i915_perf_open_param param = {
+		.flags = I915_PERF_FLAG_FD_CLOEXEC |
+		         I915_PERF_FLAG_FD_NONBLOCK |
+		         I915_PERF_FLAG_DISABLED,
+		.num_properties = ARRAY_SIZE(properties) / 2,
+		.properties_ptr = to_user_pointer(properties),
+	};
+	struct pollfd pollfd = { .events = POLLIN };
+	struct drm_i915_perf_record_header *header;
+	int buf_size = 65536 * (256 + sizeof(struct drm_i915_perf_record_header));
+	uint8_t *buf = malloc(buf_size);
+	uint32_t n_reports = 0, expected_reports, min_reports, max_reports;
+	int ret;
+
+	expected_reports = n_full_oa_reports / 5;
+	min_reports = expected_reports - expected_reports * 0.05;
+	max_reports = expected_reports + expected_reports * 0.05;
+
+	stream_fd = __perf_open(drm_fd, &param, false /* prevent_pm */);
+	pollfd.fd = stream_fd;
+
+	igt_debug("Fill duration for %s\n", pretty_print_oa_period(fill_duration));
+	igt_debug("Polling for %s\n", pretty_print_oa_period(fill_duration / 5));
+
+	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
+
+	/*
+	 * Wait for a fifth the fill duration, no data should be
+	 * available through poll()/read().
+	 */
+	while ((ret = poll(&pollfd, 1, fill_duration / (5 * 1000 * 1000))) < 0 &&
+	       errno == EINTR)
+		;
+
+	igt_assert_eq(ret, 0);
+	igt_assert_eq(pollfd.revents, 0);
+
+	while ((ret = read(stream_fd, buf, MAX_OA_BUF_SIZE)) < 0 &&
+	       errno == EINTR)
+		;
+
+	igt_assert_eq(ret, -1);
+	igt_assert_eq(errno, EAGAIN);
+
+	/* Now force the driver to look at the head/tail pointers. */
+	ret = igt_ioctl(stream_fd, I915_PERF_IOCTL_FLUSH_DATA, 0);
+
+	/* Is this supported on this kernel? */
+	igt_skip_on(ret == -1 && errno == EINVAL);
+
+	/* Now poll() should report available data. */
+	while ((ret = poll(&pollfd, 1, 0)) < 0 &&
+	       errno == EINTR)
+		;
+
+	igt_assert_eq(ret, 1);
+	igt_assert(pollfd.revents & POLLIN);
+
+	/* And we should be able to read it. */
+	while ((ret = read(stream_fd, buf, MAX_OA_BUF_SIZE)) < 0 &&
+	       errno == EINTR)
+		;
+
+	igt_assert_lte(report_size, ret);
+
+	for (int offset = 0; offset < ret; offset += header->size) {
+		header = (void *)(buf + offset);
+
+		switch (header->type) {
+		case DRM_I915_PERF_RECORD_SAMPLE:
+			n_reports++;
+			break;
+		case DRM_I915_PERF_RECORD_OA_BUFFER_LOST:
+			igt_assert(!"unexpected overflow");
+			break;
+		}
+	}
+
+	igt_debug("Got %i report(s), expected range [%u, %u]\n",
+		  n_reports, min_reports, max_reports);
+
+	/*
+	 * Verify that we get about a third of the OA buffer full of
+	 * report as we've waited for a third of the time it teakes to
+	 * fill the buffer.
+	 */
+	igt_assert_lte(n_reports, max_reports);
+	igt_assert_lte(min_reports, n_reports);
+
+	free(buf);
+
+	__perf_close(stream_fd);
+}
+
 static unsigned long rc6_residency_ms(void)
 {
 	return sysfs_read("power/rc6_residency_ms");
@@ -4871,6 +4994,13 @@ igt_main
 			       (fill_time / 4) * max_reports / fill_time);
 	}
 
+	igt_describe("Test flush data to capture all reports in interrupt mode with hrtimer disabled");
+	igt_subtest("flush-data") {
+		igt_require(i915_perf_revision(drm_fd) >= 6);
+
+		test_flush_data();
+	}
+
 	igt_subtest("short-reads")
 		test_short_reads();
 
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [PATCH i-g-t 6/6] tools: Enable interrupt support in i915 perf recorder

[Umesh Nerlige Ramappa]

Add poll delay and the interrupt mode parameters to the
i915-perf-recorder tool.

Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
---
 tools/i915-perf/i915_perf_recorder.c | 53 ++++++++++++++++++++++++++--
 1 file changed, 50 insertions(+), 3 deletions(-)

diff --git a/tools/i915-perf/i915_perf_recorder.c b/tools/i915-perf/i915_perf_recorder.c
index 6bbc451e..397e410d 100644
--- a/tools/i915-perf/i915_perf_recorder.c
+++ b/tools/i915-perf/i915_perf_recorder.c
@@ -353,14 +353,32 @@ struct recording_context {
 
 	const char *command_fifo;
 	int command_fifo_fd;
+
+	bool interrupt_mode;
+	uint32_t poll_delay;
 };
 
+static int
+perf_revision(int drm_fd)
+{
+	drm_i915_getparam_t gp;
+	int value = 1;
+
+	gp.param = I915_PARAM_PERF_REVISION;
+	gp.value = &value;
+	perf_ioctl(drm_fd, DRM_IOCTL_I915_GETPARAM, &gp);
+
+	return value;
+}
+
 static int
 perf_open(struct recording_context *ctx)
 {
 	uint64_t properties[DRM_I915_PERF_PROP_MAX * 2];
 	struct drm_i915_perf_open_param param;
-	int p = 0, stream_fd;
+	int p = 0, stream_fd, revision;
+
+	revision = perf_revision(ctx->drm_fd);
 
 	properties[p++] = DRM_I915_PERF_PROP_SAMPLE_OA;
 	properties[p++] = true;
@@ -374,6 +392,16 @@ perf_open(struct recording_context *ctx)
 	properties[p++] = DRM_I915_PERF_PROP_OA_EXPONENT;
 	properties[p++] = ctx->oa_exponent;
 
+	if (revision >= 4) {
+		properties[p++] = DRM_I915_PERF_PROP_POLL_OA_DELAY;
+		properties[p++] = ctx->poll_delay;
+	}
+
+	if (revision >= 5) {
+		properties[p++] = DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT;
+		properties[p++] = ctx->interrupt_mode;
+	}
+
 	memset(&param, 0, sizeof(param));
 	param.flags = 0;
 	param.flags |= I915_PERF_FLAG_FD_CLOEXEC | I915_PERF_FLAG_FD_NONBLOCK;
@@ -720,7 +748,13 @@ usage(const char *name)
 		"                                       (To use with i915-perf-control)\n"
 		"     --output,             -o <path>   Output file (default = i915_perf.record)\n"
 		"     --cpu-clock,          -k <path>   Cpu clock to use for correlations\n"
-		"                                       Values: boot, mono, mono_raw (default = mono)\n",
+		"                                       Values: boot, mono, mono_raw (default = mono)\n"
+		"     --interrupt-mode      -i          Enable interrupt mode in driver to query for OA reports.\n"
+		"                                       (default: interrupt-mode is disabled)\n"
+		"     --poll-delay          -P <value>  Polling interval in microseconds used by a timer in the driver to query\n"
+		"                                       for OA reports periodically\n"
+		"                                       (default = 5000), Minimum = 100. A value of 0 disables the timer and can be\n"
+	       	"                                       used only if interrupt-mode is enabled\n",
 		name);
 }
 
@@ -762,6 +796,8 @@ main(int argc, char *argv[])
 		{"size",                 required_argument, 0, 's'},
 		{"command-fifo",         required_argument, 0, 'f'},
 		{"cpu-clock",            required_argument, 0, 'k'},
+		{"interrupt-mode",             no_argument, 0, 'i'},
+		{"poll-delay",           required_argument, 0, 'P'},
 		{0, 0, 0, 0}
 	};
 	const struct {
@@ -788,9 +824,12 @@ main(int argc, char *argv[])
 
 		.command_fifo = I915_PERF_RECORD_FIFO_PATH,
 		.command_fifo_fd = -1,
+
+		.interrupt_mode = false,
+		.poll_delay = 5 * 1000 * 1000,
 	};
 
-	while ((opt = getopt_long(argc, argv, "hc:p:m:Co:s:f:k:", long_options, NULL)) != -1) {
+	while ((opt = getopt_long(argc, argv, "hc:p:m:Co:s:f:k:iP:", long_options, NULL)) != -1) {
 		switch (opt) {
 		case 'h':
 			usage(argv[0]);
@@ -832,6 +871,14 @@ main(int argc, char *argv[])
 			}
 			break;
 		}
+		case 'i':
+			ctx.interrupt_mode = true;
+			break;
+		case 'P': {
+			int pd = atoi(optarg);
+			ctx.poll_delay = pd ? MAX(100, pd) * 1000 : 0;
+			break;
+		}
 		default:
 			fprintf(stderr, "Internal error: "
 				"unexpected getopt value: %d\n", opt);
-- 
2.20.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Umesh Nerlige Ramappa]

On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige Ramappa wrote:
>Running ./build/tests/perf will run all the perf subtests in a sequence.
>When running tests in a sequence, subsequent tests may not run with a
>clean slate. For resources that are lazily released, drop caches in
>__perf_close.

Hi Lionel, Chris,

I notice an issue on TGL when running the entire suite of perf tests.  
In my setup, the polling test was failing with invalid reports being 
seen in the beginning of the OA buffer. This issue is seen more 
prominently with the newly added subtests which call perf_open and 
perf_close a couple of times (say blocking-with-interrupt).

What I see in some runs is that the second test would result in a bunch 
of unlanded reports in the beginning of the OA buffer. Assuming that we 
are already waiting for the NOA config with a noa_wait bo, I tried to 
look into this further.

free_oa_buffer is called to free the oa_buffer bo and this work is 
deferred by the driver. If a test is called before this free completes, 
we see the issue. Just to test out this theory, if I comment out the 
free_oa_buffer entirely, I see that the tests pass without any issues 
since new gtt memory is being allocated each time.

I guess the deferred free and the new allocation of the OA buffer for 
subsequent test has something missing. Maybe TLBs not being dropped? I 
imagine the OA unit might write valid reports somewhere based on what it 
sees in the TLBs and cpu is looking for them elsewhere (until the free 
completes). Just a theory though. Let me know what you think.

For now igt_drop_caches_set(DROP_FREED) is what is helping and hence 
this patch.

Thanks,
Umesh

>
>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>---
> tests/perf.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
>diff --git a/tests/perf.c b/tests/perf.c
>index 5e818030..189c6aa1 100644
>--- a/tests/perf.c
>+++ b/tests/perf.c
>@@ -244,6 +244,12 @@ __perf_close(int fd)
> 		close(pm_fd);
> 		pm_fd = -1;
> 	}
>+
>+	/* When running tests in a sequence, subsequent tests may not run with a
>+	 * clean slate. For resources that are lazily released, cleanup here.
>+	 */
>+	if (drm_fd >= 0 && !getgid() && !getuid())
>+		gem_quiescent_gpu(drm_fd);
> }
>
> static int
>@@ -3993,7 +3999,6 @@ test_rc6_disable(void)
> 	igt_assert_eq(n_events_end - n_events_start, 0);
>
> 	__perf_close(stream_fd);
>-	gem_quiescent_gpu(drm_fd);
>
> 	n_events_start = rc6_residency_ms();
> 	nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, NULL);
>-- 
>2.20.1
>
>_______________________________________________
>igt-dev mailing list
>igt-dev@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for Add igt tests for perf OA interrupts

[Patchwork]

== Series Details ==

Series: Add igt tests for perf OA interrupts
URL   : https://patchwork.freedesktop.org/series/74229/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8059 -> IGTPW_4252
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/index.html

Known issues
------------

  Here are the changes found in IGTPW_4252 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_addfb_basic@basic:
    - fi-tgl-y:           [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-tgl-y/igt@kms_addfb_basic@basic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-tgl-y/igt@kms_addfb_basic@basic.html

  * igt@kms_chamelium@dp-edid-read:
    - fi-icl-u2:          [PASS][3] -> [FAIL][4] ([fdo#109635] / [i915#217])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-icl-u2/igt@kms_chamelium@dp-edid-read.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-icl-u2/igt@kms_chamelium@dp-edid-read.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s4-devices:
    - fi-tgl-y:           [FAIL][5] ([CI#94]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html

  * igt@gem_mmap@basic:
    - fi-tgl-y:           [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-tgl-y/igt@gem_mmap@basic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-tgl-y/igt@gem_mmap@basic.html

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-guc:         [FAIL][9] ([i915#579]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html

  * igt@i915_selftest@live@gem_contexts:
    - fi-cml-s:           [DMESG-FAIL][11] ([i915#877]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
    - fi-cfl-guc:         [INCOMPLETE][13] ([fdo#106070] / [i915#424]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html

  
  [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (48 -> 46)
------------------------------

  Additional (2): fi-kbl-7560u fi-cfl-8109u 
  Missing    (4): fi-byt-clapper fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5489 -> IGTPW_4252

  CI-20190529: 20190529
  CI_DRM_8059: 1beee9fc089828e40507003ffeaeef0697345be7 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4252: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/index.html
  IGT_5489: f74d9ecfb482388b05f6902b29e64c031989ad33 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@perf@blocking-parameterized
+igt@perf@blocking-with-interrupt
+igt@perf@flush-data
+igt@perf@polling-parameterized
+igt@perf@polling-with-interrupt

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Lionel Landwerlin]

On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
> On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige Ramappa wrote:
>> Running ./build/tests/perf will run all the perf subtests in a sequence.
>> When running tests in a sequence, subsequent tests may not run with a
>> clean slate. For resources that are lazily released, drop caches in
>> __perf_close.
>
> Hi Lionel, Chris,
>
> I notice an issue on TGL when running the entire suite of perf tests.  
> In my setup, the polling test was failing with invalid reports being 
> seen in the beginning of the OA buffer. This issue is seen more 
> prominently with the newly added subtests which call perf_open and 
> perf_close a couple of times (say blocking-with-interrupt).
>
> What I see in some runs is that the second test would result in a 
> bunch of unlanded reports in the beginning of the OA buffer. Assuming 
> that we are already waiting for the NOA config with a noa_wait bo, I 
> tried to look into this further.
>
> free_oa_buffer is called to free the oa_buffer bo and this work is 
> deferred by the driver. If a test is called before this free 
> completes, we see the issue. Just to test out this theory, if I 
> comment out the free_oa_buffer entirely, I see that the tests pass 
> without any issues since new gtt memory is being allocated each time.
>
> I guess the deferred free and the new allocation of the OA buffer for 
> subsequent test has something missing. Maybe TLBs not being dropped? I 
> imagine the OA unit might write valid reports somewhere based on what 
> it sees in the TLBs and cpu is looking for them elsewhere (until the 
> free completes). Just a theory though. Let me know what you think.
>
> For now igt_drop_caches_set(DROP_FREED) is what is helping and hence 
> this patch.


Hey Umesh,


I guess this could be fixed by this commit :


commit 4b4e973d5eb89244b67d3223b60f752d0479f253
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 2 08:57:57 2020 +0000

     drm/i915/perf: Reintroduce wait on OA configuration completion

If you can give this commit a try or rebase on drm-tip it would be great 
to confirm.

Otherwise we might need more digging to figure what's going on.


Thanks,


-Lionel


>
> Thanks,
> Umesh
>
>>
>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>> ---
>> tests/perf.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/tests/perf.c b/tests/perf.c
>> index 5e818030..189c6aa1 100644
>> --- a/tests/perf.c
>> +++ b/tests/perf.c
>> @@ -244,6 +244,12 @@ __perf_close(int fd)
>>         close(pm_fd);
>>         pm_fd = -1;
>>     }
>> +
>> +    /* When running tests in a sequence, subsequent tests may not 
>> run with a
>> +     * clean slate. For resources that are lazily released, cleanup 
>> here.
>> +     */
>> +    if (drm_fd >= 0 && !getgid() && !getuid())
>> +        gem_quiescent_gpu(drm_fd);
>> }
>>
>> static int
>> @@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>     igt_assert_eq(n_events_end - n_events_start, 0);
>>
>>     __perf_close(stream_fd);
>> -    gem_quiescent_gpu(drm_fd);
>>
>>     n_events_start = rc6_residency_ms();
>>     nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, NULL);
>> -- 
>> 2.20.1
>>
>> _______________________________________________
>> igt-dev mailing list
>> igt-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/igt-dev


_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✗ Fi.CI.IGT: failure for Add igt tests for perf OA interrupts

[Patchwork]

== Series Details ==

Series: Add igt tests for perf OA interrupts
URL   : https://patchwork.freedesktop.org/series/74229/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8059_full -> IGTPW_4252_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_4252_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_4252_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_4252_full:

### IGT changes ###

#### Possible regressions ####

  * {igt@perf@flush-data} (NEW):
    - shard-iclb:         NOTRUN -> [SKIP][1] +4 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb6/igt@perf@flush-data.html

  * igt@perf@oa-exponents:
    - shard-tglb:         [PASS][2] -> [TIMEOUT][3]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-tglb7/igt@perf@oa-exponents.html
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-tglb3/igt@perf@oa-exponents.html

  * {igt@perf@polling-with-interrupt} (NEW):
    - shard-tglb:         NOTRUN -> [SKIP][4] +4 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-tglb6/igt@perf@polling-with-interrupt.html

  
#### Warnings ####

  * igt@gem_exec_schedule@pi-userfault-bsd2:
    - shard-iclb:         [SKIP][5] ([fdo#109276]) -> [INCOMPLETE][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb8/igt@gem_exec_schedule@pi-userfault-bsd2.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb1/igt@gem_exec_schedule@pi-userfault-bsd2.html

  
New tests
---------

  New tests have been introduced between CI_DRM_8059_full and IGTPW_4252_full:

### New IGT tests (5) ###

  * igt@perf@blocking-parameterized:
    - Statuses : 5 skip(s)
    - Exec time: [0.0] s

  * igt@perf@blocking-with-interrupt:
    - Statuses : 5 skip(s)
    - Exec time: [0.0] s

  * igt@perf@flush-data:
    - Statuses : 7 skip(s)
    - Exec time: [0.0] s

  * igt@perf@polling-parameterized:
    - Statuses : 7 skip(s)
    - Exec time: [0.0] s

  * igt@perf@polling-with-interrupt:
    - Statuses : 7 skip(s)
    - Exec time: [0.0] s

  

Known issues
------------

  Here are the changes found in IGTPW_4252_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@busy-vcs1:
    - shard-iclb:         [PASS][7] -> [SKIP][8] ([fdo#112080]) +14 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb2/igt@gem_busy@busy-vcs1.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb6/igt@gem_busy@busy-vcs1.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][9] -> [SKIP][10] ([fdo#110854])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb4/igt@gem_exec_balancer@smoke.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb3/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@implicit-read-write-bsd:
    - shard-iclb:         [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb6/igt@gem_exec_schedule@implicit-read-write-bsd.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb1/igt@gem_exec_schedule@implicit-read-write-bsd.html

  * igt@gem_exec_schedule@pi-common-bsd1:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([fdo#109276]) +12 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb1/igt@gem_exec_schedule@pi-common-bsd1.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb6/igt@gem_exec_schedule@pi-common-bsd1.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [PASS][15] -> [SKIP][16] ([fdo#112146]) +5 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb3/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-kbl:          [PASS][17] -> [DMESG-WARN][18] ([i915#180])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-kbl7/igt@gem_workarounds@suspend-resume-context.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-kbl1/igt@gem_workarounds@suspend-resume-context.html

  * igt@i915_suspend@sysfs-reader:
    - shard-apl:          [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-apl1/igt@i915_suspend@sysfs-reader.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-apl6/igt@i915_suspend@sysfs-reader.html

  * igt@kms_invalid_dotclock:
    - shard-apl:          [PASS][21] -> [INCOMPLETE][22] ([fdo#103927])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-apl7/igt@kms_invalid_dotclock.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-apl8/igt@kms_invalid_dotclock.html

  * igt@kms_plane@plane-position-covered-pipe-a-planes:
    - shard-apl:          [PASS][23] -> [FAIL][24] ([i915#247])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-apl8/igt@kms_plane@plane-position-covered-pipe-a-planes.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-apl7/igt@kms_plane@plane-position-covered-pipe-a-planes.html
    - shard-kbl:          [PASS][25] -> [FAIL][26] ([i915#247])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-kbl1/igt@kms_plane@plane-position-covered-pipe-a-planes.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-kbl6/igt@kms_plane@plane-position-covered-pipe-a-planes.html

  * igt@kms_psr@psr2_basic:
    - shard-iclb:         [PASS][27] -> [SKIP][28] ([fdo#109441])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb2/igt@kms_psr@psr2_basic.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb8/igt@kms_psr@psr2_basic.html

  
#### Possible fixes ####

  * igt@gem_exec_schedule@implicit-write-read-bsd2:
    - shard-iclb:         [SKIP][29] ([fdo#109276] / [i915#677]) -> [PASS][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb8/igt@gem_exec_schedule@implicit-write-read-bsd2.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb4/igt@gem_exec_schedule@implicit-write-read-bsd2.html

  * igt@gem_exec_schedule@independent-bsd:
    - shard-iclb:         [SKIP][31] ([fdo#112146]) -> [PASS][32] +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb2/igt@gem_exec_schedule@independent-bsd.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb7/igt@gem_exec_schedule@independent-bsd.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
    - shard-iclb:         [SKIP][33] ([i915#677]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb2/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb5/igt@gem_exec_schedule@pi-distinct-iova-bsd.html

  * igt@gem_exec_whisper@basic-queues-forked:
    - shard-glk:          [INCOMPLETE][35] ([i915#58] / [k.org#198133]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-glk9/igt@gem_exec_whisper@basic-queues-forked.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-glk2/igt@gem_exec_whisper@basic-queues-forked.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
    - shard-apl:          [DMESG-WARN][37] ([i915#180]) -> [PASS][38] +2 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-apl4/igt@i915_suspend@fence-restore-tiled2untiled.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-apl2/igt@i915_suspend@fence-restore-tiled2untiled.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
    - shard-hsw:          [FAIL][39] ([i915#57]) -> [PASS][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-hsw5/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-hsw7/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html

  * igt@kms_flip@flip-vs-dpms-interruptible:
    - shard-apl:          [DMESG-WARN][41] ([i915#1297]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-apl6/igt@kms_flip@flip-vs-dpms-interruptible.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-apl3/igt@kms_flip@flip-vs-dpms-interruptible.html
    - shard-kbl:          [DMESG-WARN][43] ([i915#1297]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-kbl2/igt@kms_flip@flip-vs-dpms-interruptible.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-kbl6/igt@kms_flip@flip-vs-dpms-interruptible.html

  * igt@kms_pipe_crc_basic@read-crc-pipe-b:
    - shard-snb:          [SKIP][45] ([fdo#109271]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-snb6/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-snb5/igt@kms_pipe_crc_basic@read-crc-pipe-b.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-glk:          [FAIL][47] ([i915#899]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-glk8/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-glk1/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr2_su@page_flip:
    - shard-iclb:         [SKIP][49] ([fdo#109642] / [fdo#111068]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb1/igt@kms_psr2_su@page_flip.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb2/igt@kms_psr2_su@page_flip.html

  * igt@kms_setmode@basic:
    - shard-hsw:          [FAIL][51] ([i915#31]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-hsw8/igt@kms_setmode@basic.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-hsw7/igt@kms_setmode@basic.html

  * igt@perf_pmu@busy-vcs1:
    - shard-iclb:         [SKIP][53] ([fdo#112080]) -> [PASS][54] +5 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb7/igt@perf_pmu@busy-vcs1.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb4/igt@perf_pmu@busy-vcs1.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][55] ([fdo#109276]) -> [PASS][56] +13 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb5/igt@prime_vgem@fence-wait-bsd2.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb4/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_userptr_blits@dmabuf-unsync:
    - shard-hsw:          [DMESG-WARN][57] ([fdo#111870]) -> [DMESG-WARN][58] ([fdo#110789] / [fdo#111870])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-hsw5/igt@gem_userptr_blits@dmabuf-unsync.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-hsw8/igt@gem_userptr_blits@dmabuf-unsync.html
    - shard-snb:          [DMESG-WARN][59] ([fdo#111870] / [i915#478]) -> [DMESG-WARN][60] ([fdo#110789] / [fdo#111870] / [i915#478])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-snb2/igt@gem_userptr_blits@dmabuf-unsync.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-snb5/igt@gem_userptr_blits@dmabuf-unsync.html

  * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
    - shard-hsw:          [DMESG-WARN][61] ([fdo#110789] / [fdo#111870]) -> [DMESG-WARN][62] ([fdo#111870])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-hsw1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-hsw1/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-tglb:         [SKIP][63] ([i915#468]) -> [FAIL][64] ([i915#454])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-tglb2/igt@i915_pm_dc@dc6-psr.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-tglb8/igt@i915_pm_dc@dc6-psr.html

  * igt@i915_pm_rpm@gem-execbuf-stress-pc8:
    - shard-iclb:         [SKIP][65] ([i915#1316]) -> [SKIP][66] ([fdo#109293] / [fdo#109506])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb1/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb8/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
    - shard-tglb:         [SKIP][67] ([i915#1316]) -> [SKIP][68] ([fdo#109506])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-tglb2/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-tglb3/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html

  * igt@kms_dp_dsc@basic-dsc-enable-edp:
    - shard-iclb:         [DMESG-WARN][69] ([i915#1226]) -> [SKIP][70] ([fdo#109349])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8059/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/shard-iclb5/igt@kms_dp_dsc@basic-dsc-enable-edp.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109293]: https://bugs.freedesktop.org/show_bug.cgi?id=109293
  [fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
  [i915#1297]: https://gitlab.freedesktop.org/drm/intel/issues/1297
  [i915#1316]: https://gitlab.freedesktop.org/drm/intel/issues/1316
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#247]: https://gitlab.freedesktop.org/drm/intel/issues/247
  [i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
  [i915#478]: https://gitlab.freedesktop.org/drm/intel/issues/478
  [i915#57]: https://gitlab.freedesktop.org/drm/intel/issues/57
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
  [i915#899]: https://gitlab.freedesktop.org/drm/intel/issues/899
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (10 -> 8)
------------------------------

  Missing    (2): pig-skl-6260u pig-glk-j5005 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5489 -> IGTPW_4252
  * Piglit: piglit_4509 -> None

  CI-20190529: 20190529
  CI_DRM_8059: 1beee9fc089828e40507003ffeaeef0697345be7 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4252: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/index.html
  IGT_5489: f74d9ecfb482388b05f6902b29e64c031989ad33 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4252/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Umesh Nerlige Ramappa]

On Wed, Mar 04, 2020 at 10:45:55AM +0200, Lionel Landwerlin wrote:
>On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
>>On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige Ramappa wrote:
>>>Running ./build/tests/perf will run all the perf subtests in a sequence.
>>>When running tests in a sequence, subsequent tests may not run with a
>>>clean slate. For resources that are lazily released, drop caches in
>>>__perf_close.
>>
>>Hi Lionel, Chris,
>>
>>I notice an issue on TGL when running the entire suite of perf 
>>tests.  In my setup, the polling test was failing with invalid 
>>reports being seen in the beginning of the OA buffer. This issue is 
>>seen more prominently with the newly added subtests which call 
>>perf_open and perf_close a couple of times (say 
>>blocking-with-interrupt).
>>
>>What I see in some runs is that the second test would result in a 
>>bunch of unlanded reports in the beginning of the OA buffer. 
>>Assuming that we are already waiting for the NOA config with a 
>>noa_wait bo, I tried to look into this further.
>>
>>free_oa_buffer is called to free the oa_buffer bo and this work is 
>>deferred by the driver. If a test is called before this free 
>>completes, we see the issue. Just to test out this theory, if I 
>>comment out the free_oa_buffer entirely, I see that the tests pass 
>>without any issues since new gtt memory is being allocated each 
>>time.
>>
>>I guess the deferred free and the new allocation of the OA buffer 
>>for subsequent test has something missing. Maybe TLBs not being 
>>dropped? I imagine the OA unit might write valid reports somewhere 
>>based on what it sees in the TLBs and cpu is looking for them 
>>elsewhere (until the free completes). Just a theory though. Let me 
>>know what you think.
>>
>>For now igt_drop_caches_set(DROP_FREED) is what is helping and hence 
>>this patch.
>
>
>Hey Umesh,
>
>
>I guess this could be fixed by this commit :
>
>
>commit 4b4e973d5eb89244b67d3223b60f752d0479f253
>Author: Chris Wilson <chris@chris-wilson.co.uk>
>Date:   Mon Mar 2 08:57:57 2020 +0000
>
>    drm/i915/perf: Reintroduce wait on OA configuration completion
>
>If you can give this commit a try or rebase on drm-tip it would be 
>great to confirm.

I thought this commit was ensuring that the noa_wait is executed 
completely before we enable the OA buffer captures. That still does not 
explain why the issue goes away for me when I comment out 
free_oa_buffer.

Thanks,
Umesh

>
>Otherwise we might need more digging to figure what's going on.
>
>
>Thanks,
>
>
>-Lionel
>
>
>>
>>Thanks,
>>Umesh
>>
>>>
>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>---
>>>tests/perf.c | 7 ++++++-
>>>1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>>diff --git a/tests/perf.c b/tests/perf.c
>>>index 5e818030..189c6aa1 100644
>>>--- a/tests/perf.c
>>>+++ b/tests/perf.c
>>>@@ -244,6 +244,12 @@ __perf_close(int fd)
>>>        close(pm_fd);
>>>        pm_fd = -1;
>>>    }
>>>+
>>>+    /* When running tests in a sequence, subsequent tests may not 
>>>run with a
>>>+     * clean slate. For resources that are lazily released, 
>>>cleanup here.
>>>+     */
>>>+    if (drm_fd >= 0 && !getgid() && !getuid())
>>>+        gem_quiescent_gpu(drm_fd);
>>>}
>>>
>>>static int
>>>@@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>>    igt_assert_eq(n_events_end - n_events_start, 0);
>>>
>>>    __perf_close(stream_fd);
>>>-    gem_quiescent_gpu(drm_fd);
>>>
>>>    n_events_start = rc6_residency_ms();
>>>    nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, NULL);
>>>-- 
>>>2.20.1
>>>
>>>_______________________________________________
>>>igt-dev mailing list
>>>igt-dev@lists.freedesktop.org
>>>https://lists.freedesktop.org/mailman/listinfo/igt-dev
>
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Lionel Landwerlin]

On 04/03/2020 19:51, Umesh Nerlige Ramappa wrote:
> On Wed, Mar 04, 2020 at 10:45:55AM +0200, Lionel Landwerlin wrote:
>> On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
>>> On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige Ramappa wrote:
>>>> Running ./build/tests/perf will run all the perf subtests in a 
>>>> sequence.
>>>> When running tests in a sequence, subsequent tests may not run with a
>>>> clean slate. For resources that are lazily released, drop caches in
>>>> __perf_close.
>>>
>>> Hi Lionel, Chris,
>>>
>>> I notice an issue on TGL when running the entire suite of perf 
>>> tests.  In my setup, the polling test was failing with invalid 
>>> reports being seen in the beginning of the OA buffer. This issue is 
>>> seen more prominently with the newly added subtests which call 
>>> perf_open and perf_close a couple of times (say 
>>> blocking-with-interrupt).
>>>
>>> What I see in some runs is that the second test would result in a 
>>> bunch of unlanded reports in the beginning of the OA buffer. 
>>> Assuming that we are already waiting for the NOA config with a 
>>> noa_wait bo, I tried to look into this further.
>>>
>>> free_oa_buffer is called to free the oa_buffer bo and this work is 
>>> deferred by the driver. If a test is called before this free 
>>> completes, we see the issue. Just to test out this theory, if I 
>>> comment out the free_oa_buffer entirely, I see that the tests pass 
>>> without any issues since new gtt memory is being allocated each time.
>>>
>>> I guess the deferred free and the new allocation of the OA buffer 
>>> for subsequent test has something missing. Maybe TLBs not being 
>>> dropped? I imagine the OA unit might write valid reports somewhere 
>>> based on what it sees in the TLBs and cpu is looking for them 
>>> elsewhere (until the free completes). Just a theory though. Let me 
>>> know what you think.
>>>
>>> For now igt_drop_caches_set(DROP_FREED) is what is helping and hence 
>>> this patch.
>>
>>
>> Hey Umesh,
>>
>>
>> I guess this could be fixed by this commit :
>>
>>
>> commit 4b4e973d5eb89244b67d3223b60f752d0479f253
>> Author: Chris Wilson <chris@chris-wilson.co.uk>
>> Date:   Mon Mar 2 08:57:57 2020 +0000
>>
>>     drm/i915/perf: Reintroduce wait on OA configuration completion
>>
>> If you can give this commit a try or rebase on drm-tip it would be 
>> great to confirm.
>
> I thought this commit was ensuring that the noa_wait is executed 
> completely before we enable the OA buffer captures. That still does 
> not explain why the issue goes away for me when I comment out 
> free_oa_buffer.


If noa_wait is not waited upon, either from CPU or GPU, then we enable 
OA while the configuration is not completely applied.

Hence the invalid data at the beginning of the buffer.


Are you saying this commit didn't help?


Thanks,


-Lionel


>
> Thanks,
> Umesh
>
>>
>> Otherwise we might need more digging to figure what's going on.
>>
>>
>> Thanks,
>>
>>
>> -Lionel
>>
>>
>>>
>>> Thanks,
>>> Umesh
>>>
>>>>
>>>> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>> ---
>>>> tests/perf.c | 7 ++++++-
>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/tests/perf.c b/tests/perf.c
>>>> index 5e818030..189c6aa1 100644
>>>> --- a/tests/perf.c
>>>> +++ b/tests/perf.c
>>>> @@ -244,6 +244,12 @@ __perf_close(int fd)
>>>>         close(pm_fd);
>>>>         pm_fd = -1;
>>>>     }
>>>> +
>>>> +    /* When running tests in a sequence, subsequent tests may not 
>>>> run with a
>>>> +     * clean slate. For resources that are lazily released, 
>>>> cleanup here.
>>>> +     */
>>>> +    if (drm_fd >= 0 && !getgid() && !getuid())
>>>> +        gem_quiescent_gpu(drm_fd);
>>>> }
>>>>
>>>> static int
>>>> @@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>>>     igt_assert_eq(n_events_end - n_events_start, 0);
>>>>
>>>>     __perf_close(stream_fd);
>>>> -    gem_quiescent_gpu(drm_fd);
>>>>
>>>>     n_events_start = rc6_residency_ms();
>>>>     nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, NULL);
>>>> -- 
>>>> 2.20.1
>>>>
>>>> _______________________________________________
>>>> igt-dev mailing list
>>>> igt-dev@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>
>>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Umesh Nerlige Ramappa]

On Thu, Mar 05, 2020 at 12:05:55AM +0200, Lionel Landwerlin wrote:
>On 04/03/2020 19:51, Umesh Nerlige Ramappa wrote:
>>On Wed, Mar 04, 2020 at 10:45:55AM +0200, Lionel Landwerlin wrote:
>>>On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
>>>>On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige Ramappa wrote:
>>>>>Running ./build/tests/perf will run all the perf subtests in a 
>>>>>sequence.
>>>>>When running tests in a sequence, subsequent tests may not run with a
>>>>>clean slate. For resources that are lazily released, drop caches in
>>>>>__perf_close.
>>>>
>>>>Hi Lionel, Chris,
>>>>
>>>>I notice an issue on TGL when running the entire suite of perf 
>>>>tests.  In my setup, the polling test was failing with invalid 
>>>>reports being seen in the beginning of the OA buffer. This issue 
>>>>is seen more prominently with the newly added subtests which 
>>>>call perf_open and perf_close a couple of times (say 
>>>>blocking-with-interrupt).
>>>>
>>>>What I see in some runs is that the second test would result in 
>>>>a bunch of unlanded reports in the beginning of the OA buffer. 
>>>>Assuming that we are already waiting for the NOA config with a 
>>>>noa_wait bo, I tried to look into this further.
>>>>
>>>>free_oa_buffer is called to free the oa_buffer bo and this work 
>>>>is deferred by the driver. If a test is called before this free 
>>>>completes, we see the issue. Just to test out this theory, if I 
>>>>comment out the free_oa_buffer entirely, I see that the tests 
>>>>pass without any issues since new gtt memory is being allocated 
>>>>each time.
>>>>
>>>>I guess the deferred free and the new allocation of the OA 
>>>>buffer for subsequent test has something missing. Maybe TLBs not 
>>>>being dropped? I imagine the OA unit might write valid reports 
>>>>somewhere based on what it sees in the TLBs and cpu is looking 
>>>>for them elsewhere (until the free completes). Just a theory 
>>>>though. Let me know what you think.
>>>>
>>>>For now igt_drop_caches_set(DROP_FREED) is what is helping and 
>>>>hence this patch.
>>>
>>>
>>>Hey Umesh,
>>>
>>>
>>>I guess this could be fixed by this commit :
>>>
>>>
>>>commit 4b4e973d5eb89244b67d3223b60f752d0479f253
>>>Author: Chris Wilson <chris@chris-wilson.co.uk>
>>>Date:   Mon Mar 2 08:57:57 2020 +0000
>>>
>>>    drm/i915/perf: Reintroduce wait on OA configuration completion
>>>
>>>If you can give this commit a try or rebase on drm-tip it would be 
>>>great to confirm.
>>
>>I thought this commit was ensuring that the noa_wait is executed 
>>completely before we enable the OA buffer captures. That still does 
>>not explain why the issue goes away for me when I comment out 
>>free_oa_buffer.
>
>
>If noa_wait is not waited upon, either from CPU or GPU, then we enable 
>OA while the configuration is not completely applied.
>
>Hence the invalid data at the beginning of the buffer.
>
>
>Are you saying this commit didn't help?
>
No, I haven't tried it yet. I lost my reservation on the TGL machine :(, 
so waiting for another one.

What I meant is that - not freeing the OA buffer (only for 
experimenting) results in a new gtt offset everytime we allocate the OA 
buffer. When I do this, I don't see any invalid OA reports. This is 
without the commit you mention above. If waiting for the NOA config to 
complete were indeed the issue, I should have seen it even with my 
experiment. Right?

Thanks,
Umesh

>
>Thanks,
>
>
>-Lionel
>
>
>>
>>Thanks,
>>Umesh
>>
>>>
>>>Otherwise we might need more digging to figure what's going on.
>>>
>>>
>>>Thanks,
>>>
>>>
>>>-Lionel
>>>
>>>
>>>>
>>>>Thanks,
>>>>Umesh
>>>>
>>>>>
>>>>>Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>>>>>---
>>>>>tests/perf.c | 7 ++++++-
>>>>>1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>>diff --git a/tests/perf.c b/tests/perf.c
>>>>>index 5e818030..189c6aa1 100644
>>>>>--- a/tests/perf.c
>>>>>+++ b/tests/perf.c
>>>>>@@ -244,6 +244,12 @@ __perf_close(int fd)
>>>>>        close(pm_fd);
>>>>>        pm_fd = -1;
>>>>>    }
>>>>>+
>>>>>+    /* When running tests in a sequence, subsequent tests may 
>>>>>not run with a
>>>>>+     * clean slate. For resources that are lazily released, 
>>>>>cleanup here.
>>>>>+     */
>>>>>+    if (drm_fd >= 0 && !getgid() && !getuid())
>>>>>+        gem_quiescent_gpu(drm_fd);
>>>>>}
>>>>>
>>>>>static int
>>>>>@@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>>>>    igt_assert_eq(n_events_end - n_events_start, 0);
>>>>>
>>>>>    __perf_close(stream_fd);
>>>>>-    gem_quiescent_gpu(drm_fd);
>>>>>
>>>>>    n_events_start = rc6_residency_ms();
>>>>>    nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, NULL);
>>>>>-- 
>>>>>2.20.1
>>>>>
>>>>>_______________________________________________
>>>>>igt-dev mailing list
>>>>>igt-dev@lists.freedesktop.org
>>>>>https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>
>>>
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Lionel Landwerlin]

On 05/03/2020 01:04, Umesh Nerlige Ramappa wrote:
> On Thu, Mar 05, 2020 at 12:05:55AM +0200, Lionel Landwerlin wrote:
>> On 04/03/2020 19:51, Umesh Nerlige Ramappa wrote:
>>> On Wed, Mar 04, 2020 at 10:45:55AM +0200, Lionel Landwerlin wrote:
>>>> On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
>>>>> On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige Ramappa 
>>>>> wrote:
>>>>>> Running ./build/tests/perf will run all the perf subtests in a 
>>>>>> sequence.
>>>>>> When running tests in a sequence, subsequent tests may not run 
>>>>>> with a
>>>>>> clean slate. For resources that are lazily released, drop caches in
>>>>>> __perf_close.
>>>>>
>>>>> Hi Lionel, Chris,
>>>>>
>>>>> I notice an issue on TGL when running the entire suite of perf 
>>>>> tests.  In my setup, the polling test was failing with invalid 
>>>>> reports being seen in the beginning of the OA buffer. This issue 
>>>>> is seen more prominently with the newly added subtests which call 
>>>>> perf_open and perf_close a couple of times (say 
>>>>> blocking-with-interrupt).
>>>>>
>>>>> What I see in some runs is that the second test would result in a 
>>>>> bunch of unlanded reports in the beginning of the OA buffer. 
>>>>> Assuming that we are already waiting for the NOA config with a 
>>>>> noa_wait bo, I tried to look into this further.
>>>>>
>>>>> free_oa_buffer is called to free the oa_buffer bo and this work is 
>>>>> deferred by the driver. If a test is called before this free 
>>>>> completes, we see the issue. Just to test out this theory, if I 
>>>>> comment out the free_oa_buffer entirely, I see that the tests pass 
>>>>> without any issues since new gtt memory is being allocated each time.
>>>>>
>>>>> I guess the deferred free and the new allocation of the OA buffer 
>>>>> for subsequent test has something missing. Maybe TLBs not being 
>>>>> dropped? I imagine the OA unit might write valid reports somewhere 
>>>>> based on what it sees in the TLBs and cpu is looking for them 
>>>>> elsewhere (until the free completes). Just a theory though. Let me 
>>>>> know what you think.
>>>>>
>>>>> For now igt_drop_caches_set(DROP_FREED) is what is helping and 
>>>>> hence this patch.
>>>>
>>>>
>>>> Hey Umesh,
>>>>
>>>>
>>>> I guess this could be fixed by this commit :
>>>>
>>>>
>>>> commit 4b4e973d5eb89244b67d3223b60f752d0479f253
>>>> Author: Chris Wilson <chris@chris-wilson.co.uk>
>>>> Date:   Mon Mar 2 08:57:57 2020 +0000
>>>>
>>>>     drm/i915/perf: Reintroduce wait on OA configuration completion
>>>>
>>>> If you can give this commit a try or rebase on drm-tip it would be 
>>>> great to confirm.
>>>
>>> I thought this commit was ensuring that the noa_wait is executed 
>>> completely before we enable the OA buffer captures. That still does 
>>> not explain why the issue goes away for me when I comment out 
>>> free_oa_buffer.
>>
>>
>> If noa_wait is not waited upon, either from CPU or GPU, then we 
>> enable OA while the configuration is not completely applied.
>>
>> Hence the invalid data at the beginning of the buffer.
>>
>>
>> Are you saying this commit didn't help?
>>
> No, I haven't tried it yet. I lost my reservation on the TGL machine 
> :(, so waiting for another one.
>
> What I meant is that - not freeing the OA buffer (only for 
> experimenting) results in a new gtt offset everytime we allocate the 
> OA buffer. When I do this, I don't see any invalid OA reports. This is 
> without the commit you mention above. If waiting for the NOA config to 
> complete were indeed the issue, I should have seen it even with my 
> experiment. Right?


I see, thanks that's a useful experiment.

Only thing I can think of would be HEAD/TAIL register writes that didn't 
land before the OA unit was turned on.

I'll dig into the code.


Is this only on Gen12?


Thanks,


-Lionel


>
> Thanks,
> Umesh
>
>>
>> Thanks,
>>
>>
>> -Lionel
>>
>>
>>>
>>> Thanks,
>>> Umesh
>>>
>>>>
>>>> Otherwise we might need more digging to figure what's going on.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> -Lionel
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Umesh
>>>>>
>>>>>>
>>>>>> Signed-off-by: Umesh Nerlige Ramappa 
>>>>>> <umesh.nerlige.ramappa@intel.com>
>>>>>> ---
>>>>>> tests/perf.c | 7 ++++++-
>>>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/tests/perf.c b/tests/perf.c
>>>>>> index 5e818030..189c6aa1 100644
>>>>>> --- a/tests/perf.c
>>>>>> +++ b/tests/perf.c
>>>>>> @@ -244,6 +244,12 @@ __perf_close(int fd)
>>>>>>         close(pm_fd);
>>>>>>         pm_fd = -1;
>>>>>>     }
>>>>>> +
>>>>>> +    /* When running tests in a sequence, subsequent tests may 
>>>>>> not run with a
>>>>>> +     * clean slate. For resources that are lazily released, 
>>>>>> cleanup here.
>>>>>> +     */
>>>>>> +    if (drm_fd >= 0 && !getgid() && !getuid())
>>>>>> +        gem_quiescent_gpu(drm_fd);
>>>>>> }
>>>>>>
>>>>>> static int
>>>>>> @@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>>>>>     igt_assert_eq(n_events_end - n_events_start, 0);
>>>>>>
>>>>>>     __perf_close(stream_fd);
>>>>>> -    gem_quiescent_gpu(drm_fd);
>>>>>>
>>>>>>     n_events_start = rc6_residency_ms();
>>>>>>     nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 0 }, 
>>>>>> NULL);
>>>>>> -- 
>>>>>> 2.20.1
>>>>>>
>>>>>> _______________________________________________
>>>>>> igt-dev mailing list
>>>>>> igt-dev@lists.freedesktop.org
>>>>>> https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>
>>>>
>>

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Umesh Nerlige Ramappa]

On Thu, Mar 05, 2020 at 01:29:50AM +0200, Lionel Landwerlin wrote:
>On 05/03/2020 01:04, Umesh Nerlige Ramappa wrote:
>>On Thu, Mar 05, 2020 at 12:05:55AM +0200, Lionel Landwerlin wrote:
>>>On 04/03/2020 19:51, Umesh Nerlige Ramappa wrote:
>>>>On Wed, Mar 04, 2020 at 10:45:55AM +0200, Lionel Landwerlin wrote:
>>>>>On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
>>>>>>On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige 
>>>>>>Ramappa wrote:
>>>>>>>Running ./build/tests/perf will run all the perf subtests 
>>>>>>>in a sequence.
>>>>>>>When running tests in a sequence, subsequent tests may not 
>>>>>>>run with a
>>>>>>>clean slate. For resources that are lazily released, drop caches in
>>>>>>>__perf_close.
>>>>>>
>>>>>>Hi Lionel, Chris,
>>>>>>
>>>>>>I notice an issue on TGL when running the entire suite of 
>>>>>>perf tests.  In my setup, the polling test was failing with 
>>>>>>invalid reports being seen in the beginning of the OA 
>>>>>>buffer. This issue is seen more prominently with the newly 
>>>>>>added subtests which call perf_open and perf_close a couple 
>>>>>>of times (say blocking-with-interrupt).
>>>>>>
>>>>>>What I see in some runs is that the second test would result 
>>>>>>in a bunch of unlanded reports in the beginning of the OA 
>>>>>>buffer. Assuming that we are already waiting for the NOA 
>>>>>>config with a noa_wait bo, I tried to look into this 
>>>>>>further.
>>>>>>
>>>>>>free_oa_buffer is called to free the oa_buffer bo and this 
>>>>>>work is deferred by the driver. If a test is called before 
>>>>>>this free completes, we see the issue. Just to test out this 
>>>>>>theory, if I comment out the free_oa_buffer entirely, I see 
>>>>>>that the tests pass without any issues since new gtt memory 
>>>>>>is being allocated each time.
>>>>>>
>>>>>>I guess the deferred free and the new allocation of the OA 
>>>>>>buffer for subsequent test has something missing. Maybe TLBs 
>>>>>>not being dropped? I imagine the OA unit might write valid 
>>>>>>reports somewhere based on what it sees in the TLBs and cpu 
>>>>>>is looking for them elsewhere (until the free completes). 
>>>>>>Just a theory though. Let me know what you think.
>>>>>>
>>>>>>For now igt_drop_caches_set(DROP_FREED) is what is helping 
>>>>>>and hence this patch.
>>>>>
>>>>>
>>>>>Hey Umesh,
>>>>>
>>>>>
>>>>>I guess this could be fixed by this commit :
>>>>>
>>>>>
>>>>>commit 4b4e973d5eb89244b67d3223b60f752d0479f253
>>>>>Author: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>Date:   Mon Mar 2 08:57:57 2020 +0000
>>>>>
>>>>>    drm/i915/perf: Reintroduce wait on OA configuration completion
>>>>>
>>>>>If you can give this commit a try or rebase on drm-tip it 
>>>>>would be great to confirm.
>>>>
>>>>I thought this commit was ensuring that the noa_wait is executed 
>>>>completely before we enable the OA buffer captures. That still 
>>>>does not explain why the issue goes away for me when I comment 
>>>>out free_oa_buffer.
>>>
>>>
>>>If noa_wait is not waited upon, either from CPU or GPU, then we 
>>>enable OA while the configuration is not completely applied.
>>>
>>>Hence the invalid data at the beginning of the buffer.
>>>
>>>
>>>Are you saying this commit didn't help?
>>>
>>No, I haven't tried it yet. I lost my reservation on the TGL machine 
>>:(, so waiting for another one.
>>
>>What I meant is that - not freeing the OA buffer (only for 
>>experimenting) results in a new gtt offset everytime we allocate the 
>>OA buffer. When I do this, I don't see any invalid OA reports. This 
>>is without the commit you mention above. If waiting for the NOA 
>>config to complete were indeed the issue, I should have seen it even 
>>with my experiment. Right?
>
>
>I see, thanks that's a useful experiment.
>
>Only thing I can think of would be HEAD/TAIL register writes that 
>didn't land before the OA unit was turned on.
>
>I'll dig into the code.
>
>
>Is this only on Gen12?

Yes. On TGL, There should be 2 way to reproduce this (without the above 
commit):

1. Just run perf so that it runs all the tests (or at least blocking 
followed by polling). The polling test fails.

2. If you are applying the interrupt patches from this and the kernel 
thread, then you just need to run the blocking-with-interrupts test.

In dmesg, you will see messages for unlanded reports. That's what I am 
going by to decide if any fix/workaround worked or not.

Thanks,
Umesh
>
>
>Thanks,
>
>
>-Lionel
>
>
>>
>>Thanks,
>>Umesh
>>
>>>
>>>Thanks,
>>>
>>>
>>>-Lionel
>>>
>>>
>>>>
>>>>Thanks,
>>>>Umesh
>>>>
>>>>>
>>>>>Otherwise we might need more digging to figure what's going on.
>>>>>
>>>>>
>>>>>Thanks,
>>>>>
>>>>>
>>>>>-Lionel
>>>>>
>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>Umesh
>>>>>>
>>>>>>>
>>>>>>>Signed-off-by: Umesh Nerlige Ramappa 
>>>>>>><umesh.nerlige.ramappa@intel.com>
>>>>>>>---
>>>>>>>tests/perf.c | 7 ++++++-
>>>>>>>1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>>diff --git a/tests/perf.c b/tests/perf.c
>>>>>>>index 5e818030..189c6aa1 100644
>>>>>>>--- a/tests/perf.c
>>>>>>>+++ b/tests/perf.c
>>>>>>>@@ -244,6 +244,12 @@ __perf_close(int fd)
>>>>>>>        close(pm_fd);
>>>>>>>        pm_fd = -1;
>>>>>>>    }
>>>>>>>+
>>>>>>>+    /* When running tests in a sequence, subsequent tests 
>>>>>>>may not run with a
>>>>>>>+     * clean slate. For resources that are lazily 
>>>>>>>released, cleanup here.
>>>>>>>+     */
>>>>>>>+    if (drm_fd >= 0 && !getgid() && !getuid())
>>>>>>>+        gem_quiescent_gpu(drm_fd);
>>>>>>>}
>>>>>>>
>>>>>>>static int
>>>>>>>@@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>>>>>>    igt_assert_eq(n_events_end - n_events_start, 0);
>>>>>>>
>>>>>>>    __perf_close(stream_fd);
>>>>>>>-    gem_quiescent_gpu(drm_fd);
>>>>>>>
>>>>>>>    n_events_start = rc6_residency_ms();
>>>>>>>    nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec = 
>>>>>>>0 }, NULL);
>>>>>>>-- 
>>>>>>>2.20.1
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>igt-dev mailing list
>>>>>>>igt-dev@lists.freedesktop.org
>>>>>>>https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>>
>>>>>
>>>
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t 1/6] test/perf: Drop caches when closing perf stream

[Umesh Nerlige Ramappa]

On Wed, Mar 04, 2020 at 03:51:56PM -0800, Umesh Nerlige Ramappa wrote:
>On Thu, Mar 05, 2020 at 01:29:50AM +0200, Lionel Landwerlin wrote:
>>On 05/03/2020 01:04, Umesh Nerlige Ramappa wrote:
>>>On Thu, Mar 05, 2020 at 12:05:55AM +0200, Lionel Landwerlin wrote:
>>>>On 04/03/2020 19:51, Umesh Nerlige Ramappa wrote:
>>>>>On Wed, Mar 04, 2020 at 10:45:55AM +0200, Lionel Landwerlin wrote:
>>>>>>On 04/03/2020 00:57, Umesh Nerlige Ramappa wrote:
>>>>>>>On Tue, Mar 03, 2020 at 02:38:08PM -0800, Umesh Nerlige 
>>>>>>>Ramappa wrote:
>>>>>>>>Running ./build/tests/perf will run all the perf 
>>>>>>>>subtests in a sequence.
>>>>>>>>When running tests in a sequence, subsequent tests may 
>>>>>>>>not run with a
>>>>>>>>clean slate. For resources that are lazily released, drop caches in
>>>>>>>>__perf_close.
>>>>>>>
>>>>>>>Hi Lionel, Chris,
>>>>>>>
>>>>>>>I notice an issue on TGL when running the entire suite of 
>>>>>>>perf tests.  In my setup, the polling test was failing 
>>>>>>>with invalid reports being seen in the beginning of the OA 
>>>>>>>buffer. This issue is seen more prominently with the newly 
>>>>>>>added subtests which call perf_open and perf_close a 
>>>>>>>couple of times (say blocking-with-interrupt).
>>>>>>>
>>>>>>>What I see in some runs is that the second test would 
>>>>>>>result in a bunch of unlanded reports in the beginning of 
>>>>>>>the OA buffer. Assuming that we are already waiting for 
>>>>>>>the NOA config with a noa_wait bo, I tried to look into 
>>>>>>>this further.
>>>>>>>
>>>>>>>free_oa_buffer is called to free the oa_buffer bo and this 
>>>>>>>work is deferred by the driver. If a test is called before 
>>>>>>>this free completes, we see the issue. Just to test out 
>>>>>>>this theory, if I comment out the free_oa_buffer entirely, 
>>>>>>>I see that the tests pass without any issues since new gtt 
>>>>>>>memory is being allocated each time.
>>>>>>>
>>>>>>>I guess the deferred free and the new allocation of the OA 
>>>>>>>buffer for subsequent test has something missing. Maybe 
>>>>>>>TLBs not being dropped? I imagine the OA unit might write 
>>>>>>>valid reports somewhere based on what it sees in the TLBs 
>>>>>>>and cpu is looking for them elsewhere (until the free 
>>>>>>>completes). Just a theory though. Let me know what you 
>>>>>>>think.
>>>>>>>
>>>>>>>For now igt_drop_caches_set(DROP_FREED) is what is helping 
>>>>>>>and hence this patch.
>>>>>>
>>>>>>
>>>>>>Hey Umesh,
>>>>>>
>>>>>>
>>>>>>I guess this could be fixed by this commit :
>>>>>>
>>>>>>
>>>>>>commit 4b4e973d5eb89244b67d3223b60f752d0479f253
>>>>>>Author: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>Date:   Mon Mar 2 08:57:57 2020 +0000
>>>>>>
>>>>>>    drm/i915/perf: Reintroduce wait on OA configuration completion
>>>>>>
>>>>>>If you can give this commit a try or rebase on drm-tip it 
>>>>>>would be great to confirm.
>>>>>
>>>>>I thought this commit was ensuring that the noa_wait is 
>>>>>executed completely before we enable the OA buffer captures. 
>>>>>That still does not explain why the issue goes away for me 
>>>>>when I comment out free_oa_buffer.
>>>>
>>>>
>>>>If noa_wait is not waited upon, either from CPU or GPU, then we 
>>>>enable OA while the configuration is not completely applied.
>>>>
>>>>Hence the invalid data at the beginning of the buffer.
>>>>
>>>>
>>>>Are you saying this commit didn't help?
>>>>
>>>No, I haven't tried it yet. I lost my reservation on the TGL 
>>>machine :(, so waiting for another one.
>>>
>>>What I meant is that - not freeing the OA buffer (only for 
>>>experimenting) results in a new gtt offset everytime we allocate 
>>>the OA buffer. When I do this, I don't see any invalid OA reports. 
>>>This is without the commit you mention above. If waiting for the 
>>>NOA config to complete were indeed the issue, I should have seen 
>>>it even with my experiment. Right?
>>
>>
>>I see, thanks that's a useful experiment.
>>
>>Only thing I can think of would be HEAD/TAIL register writes that 
>>didn't land before the OA unit was turned on.
>>
>>I'll dig into the code.
>>
>>
>>Is this only on Gen12?
>
>Yes. On TGL, There should be 2 way to reproduce this (without the 
>above commit):
>
>1. Just run perf so that it runs all the tests (or at least blocking 
>followed by polling). The polling test fails.
>
>2. If you are applying the interrupt patches from this and the kernel 
>thread, then you just need to run the blocking-with-interrupts test.
>
>In dmesg, you will see messages for unlanded reports. That's what I am 
>going by to decide if any fix/workaround worked or not.
>
>Thanks,
>Umesh
>>

I rebased the kernel patches to get Chris's commit, removed 
gem_quiesce_gpu from igt tests and tried running 
blocking-with-interrupts. I still see the issue. This subtest has 4 
tests - first one passes, second one has unlanded reports, third one
causes a reboot (have to enable crash dumps to debug further).

Thanks,
Umesh

>>
>>Thanks,
>>
>>
>>-Lionel
>>
>>
>>>
>>>Thanks,
>>>Umesh
>>>
>>>>
>>>>Thanks,
>>>>
>>>>
>>>>-Lionel
>>>>
>>>>
>>>>>
>>>>>Thanks,
>>>>>Umesh
>>>>>
>>>>>>
>>>>>>Otherwise we might need more digging to figure what's going on.
>>>>>>
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>
>>>>>>-Lionel
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Umesh
>>>>>>>
>>>>>>>>
>>>>>>>>Signed-off-by: Umesh Nerlige Ramappa 
>>>>>>>><umesh.nerlige.ramappa@intel.com>
>>>>>>>>---
>>>>>>>>tests/perf.c | 7 ++++++-
>>>>>>>>1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>>diff --git a/tests/perf.c b/tests/perf.c
>>>>>>>>index 5e818030..189c6aa1 100644
>>>>>>>>--- a/tests/perf.c
>>>>>>>>+++ b/tests/perf.c
>>>>>>>>@@ -244,6 +244,12 @@ __perf_close(int fd)
>>>>>>>>        close(pm_fd);
>>>>>>>>        pm_fd = -1;
>>>>>>>>    }
>>>>>>>>+
>>>>>>>>+    /* When running tests in a sequence, subsequent 
>>>>>>>>tests may not run with a
>>>>>>>>+     * clean slate. For resources that are lazily 
>>>>>>>>released, cleanup here.
>>>>>>>>+     */
>>>>>>>>+    if (drm_fd >= 0 && !getgid() && !getuid())
>>>>>>>>+        gem_quiescent_gpu(drm_fd);
>>>>>>>>}
>>>>>>>>
>>>>>>>>static int
>>>>>>>>@@ -3993,7 +3999,6 @@ test_rc6_disable(void)
>>>>>>>>    igt_assert_eq(n_events_end - n_events_start, 0);
>>>>>>>>
>>>>>>>>    __perf_close(stream_fd);
>>>>>>>>-    gem_quiescent_gpu(drm_fd);
>>>>>>>>
>>>>>>>>    n_events_start = rc6_residency_ms();
>>>>>>>>    nanosleep(&(struct timespec){ .tv_sec = 1, .tv_nsec 
>>>>>>>>= 0 }, NULL);
>>>>>>>>-- 
>>>>>>>>2.20.1
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>igt-dev mailing list
>>>>>>>>igt-dev@lists.freedesktop.org
>>>>>>>>https://lists.freedesktop.org/mailman/listinfo/igt-dev
>>>>>>
>>>>>>
>>>>
>>
>_______________________________________________
>igt-dev mailing list
>igt-dev@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev