All of lore.kernel.org
 help / color / mirror / Atom feed
* [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
@ 2020-03-27  4:42 Ashutosh Dixit
  2020-03-27  4:50 ` Dixit, Ashutosh
                   ` (3 more replies)
  0 siblings, 4 replies; 18+ messages in thread
From: Ashutosh Dixit @ 2020-03-27  4:42 UTC (permalink / raw)
  To: igt-dev

Add a test for OA data non-blocking reads using buffers smaller than
the available data. This test would fail for perf revisions < 5
because poll would block even when data was available. Therefore the
amount of data read was limited by the buffer size and the timer
interval and it was impossible to read all available data. This issue
is fixed in perf revision 5.

v2: Complete rewrite, make test fail on existing kernels (Lionel)

Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
 tests/perf.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index 724f6f809..3dc757c3b 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -2265,6 +2265,71 @@ test_polling(void)
 	__perf_close(stream_fd);
 }
 
+static void test_polling_small_buf(void)
+{
+	int oa_exponent = max_oa_exponent_for_period_lte(40 * 1000); /* 40us */
+	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,
+	};
+	struct drm_i915_perf_open_param param = {
+		.flags = I915_PERF_FLAG_FD_CLOEXEC |
+			I915_PERF_FLAG_DISABLED |
+			I915_PERF_FLAG_FD_NONBLOCK,
+		.num_properties = NUM_PROPERTIES(properties),
+		.properties_ptr = to_user_pointer(properties),
+	};
+	uint32_t test_duration = 80 * 1000 * 1000;
+	int sample_size = (sizeof(struct drm_i915_perf_record_header) +
+				get_oa_format(test_set->perf_oa_format).size);
+	int n_expected_reports = test_duration / oa_exponent_to_ns(oa_exponent);
+	int n_expect_read_bytes = n_expected_reports * sample_size;
+	uint8_t buf[1024];
+	int n_bytes_read = 0;
+	uint32_t n_polls = 0;
+	struct timespec ts = {};
+
+	stream_fd = __perf_open(drm_fd, &param, true /* prevent_pm */);
+	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
+
+	igt_nsec_elapsed(&ts);
+
+	while (igt_nsec_elapsed(&ts) < test_duration) {
+		struct timespec poll_wait = {
+			.tv_sec = 0,
+			.tv_nsec = (test_duration - igt_nsec_elapsed(&ts)),
+		};
+		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
+		int ret;
+
+		ret = ppoll(&pollfd, 1, &poll_wait, NULL);
+
+		if (pollfd.revents & POLLIN) {
+			ret = read(stream_fd, buf, sizeof(buf));
+			if (ret >= 0)
+				n_bytes_read += ret;
+		}
+
+		n_polls++;
+
+		igt_debug("Elapsed=%lu wait=%lu\n", igt_nsec_elapsed(&ts), poll_wait.tv_nsec);
+	}
+
+	igt_info("Read %d expected %d (%.2f%% of the expected number), polls=%u\n",
+		  n_bytes_read, n_expect_read_bytes,
+		  n_bytes_read * 100.0f / n_expect_read_bytes,
+		  n_polls);
+
+	__perf_close(stream_fd);
+
+	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
+}
+
 static int
 num_valid_reports_captured(struct drm_i915_perf_open_param *param,
 			   int64_t *duration_ns)
@@ -4676,6 +4741,10 @@ igt_main
 	igt_subtest("polling")
 		test_polling();
 
+	igt_describe("Test polled read with buffer size smaller than available data");
+	igt_subtest("polling-small-buf")
+		test_polling_small_buf();
+
 	igt_subtest("short-reads")
 		test_short_reads();
 
-- 
2.25.2

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

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27  4:42 [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Ashutosh Dixit
@ 2020-03-27  4:50 ` Dixit, Ashutosh
  2020-03-27 16:09   ` Lionel Landwerlin
  2020-03-27  5:23 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2) Patchwork
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-27  4:50 UTC (permalink / raw)
  To: igt-dev

On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
> diff --git a/tests/perf.c b/tests/perf.c
> index 724f6f809..3dc757c3b 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> +static void test_polling_small_buf(void)
> +{

/snip/

> +
> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
> +}
> +

I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [igt-dev] ✓ Fi.CI.BAT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2)
  2020-03-27  4:42 [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Ashutosh Dixit
  2020-03-27  4:50 ` Dixit, Ashutosh
@ 2020-03-27  5:23 ` Patchwork
  2020-03-27 15:19 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
  2020-03-27 20:56 ` [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Umesh Nerlige Ramappa
  3 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2020-03-27  5:23 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: igt-dev

== Series Details ==

Series: tests/perf: add a test for OA data polling reads using "small" buffers (rev2)
URL   : https://patchwork.freedesktop.org/series/75100/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8198 -> IGTPW_4362
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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


Changes
-------

  No changes found


Participating hosts (40 -> 42)
------------------------------

  Additional (5): fi-hsw-peppy fi-gdg-551 fi-ivb-3770 fi-kbl-7560u fi-snb-2600 
  Missing    (3): fi-byt-clapper fi-bsw-cyan fi-hsw-4200u 


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5539 -> IGTPW_4362

  CI-20190529: 20190529
  CI_DRM_8198: a421a6390d4a76e4df310bfe9adb78dde7207249 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4362: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/index.html
  IGT_5539: e7aae12e37771a8b7796ba252574eb832a5839c3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@perf@polling-small-buf

== Logs ==

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [igt-dev] ✓ Fi.CI.IGT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2)
  2020-03-27  4:42 [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Ashutosh Dixit
  2020-03-27  4:50 ` Dixit, Ashutosh
  2020-03-27  5:23 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2) Patchwork
@ 2020-03-27 15:19 ` Patchwork
  2020-03-27 20:56 ` [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Umesh Nerlige Ramappa
  3 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2020-03-27 15:19 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: igt-dev

== Series Details ==

Series: tests/perf: add a test for OA data polling reads using "small" buffers (rev2)
URL   : https://patchwork.freedesktop.org/series/75100/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8198_full -> IGTPW_4362_full
====================================================

Summary
-------

  **WARNING**

  Minor unknown changes coming with IGTPW_4362_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_4362_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_4362/index.html

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

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

### IGT changes ###

#### Possible regressions ####

  * {igt@perf@polling-small-buf} (NEW):
    - shard-glk:          NOTRUN -> [FAIL][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk7/igt@perf@polling-small-buf.html
    - shard-tglb:         NOTRUN -> [FAIL][2]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb1/igt@perf@polling-small-buf.html
    - shard-apl:          NOTRUN -> [FAIL][3]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@perf@polling-small-buf.html
    - shard-kbl:          NOTRUN -> [FAIL][4]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl6/igt@perf@polling-small-buf.html
    - shard-iclb:         NOTRUN -> [FAIL][5]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb8/igt@perf@polling-small-buf.html

  
#### Warnings ####

  * igt@kms_crtc_background_color:
    - shard-iclb:         [SKIP][6] ([fdo#109305]) -> [SKIP][7]
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb4/igt@kms_crtc_background_color.html
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb7/igt@kms_crtc_background_color.html
    - shard-tglb:         [SKIP][8] ([i915#274]) -> [SKIP][9]
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-tglb7/igt@kms_crtc_background_color.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb5/igt@kms_crtc_background_color.html

  
New tests
---------

  New tests have been introduced between CI_DRM_8198_full and IGTPW_4362_full:

### New IGT tests (4) ###

  * igt@gem_ctx_isolation@clean:
    - Statuses :
    - Exec time: [None] s

  * igt@gem_ctx_isolation@dirty-create:
    - Statuses :
    - Exec time: [None] s

  * igt@gem_ctx_shared@exec-shared-gtt:
    - Statuses :
    - Exec time: [None] s

  * igt@perf@polling-small-buf:
    - Statuses : 5 fail(s)
    - Exec time: [0.10, 0.15] s

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_busy@extended-parallel-vcs1:
    - shard-iclb:         [PASS][10] -> [SKIP][11] ([fdo#112080]) +10 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb4/igt@gem_busy@extended-parallel-vcs1.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb6/igt@gem_busy@extended-parallel-vcs1.html

  * igt@gem_exec_schedule@independent-bsd2:
    - shard-iclb:         [PASS][12] -> [SKIP][13] ([fdo#109276]) +13 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb8/igt@gem_exec_schedule@independent-bsd2.html

  * igt@gem_exec_schedule@pi-common-bsd:
    - shard-iclb:         [PASS][14] -> [SKIP][15] ([i915#677]) +1 similar issue
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb8/igt@gem_exec_schedule@pi-common-bsd.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb1/igt@gem_exec_schedule@pi-common-bsd.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [PASS][16] -> [SKIP][17] ([fdo#112146]) +6 similar issues
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb3/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@i915_pm_rc6_residency@rc6-idle:
    - shard-snb:          [PASS][18] -> [TIMEOUT][19] ([i915#1526])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-snb1/igt@i915_pm_rc6_residency@rc6-idle.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-snb1/igt@i915_pm_rc6_residency@rc6-idle.html

  * igt@i915_pm_rpm@cursor-dpms:
    - shard-hsw:          [PASS][20] -> [SKIP][21] ([fdo#109271])
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-hsw4/igt@i915_pm_rpm@cursor-dpms.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw6/igt@i915_pm_rpm@cursor-dpms.html
    - shard-glk:          [PASS][22] -> [SKIP][23] ([fdo#109271])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk6/igt@i915_pm_rpm@cursor-dpms.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk4/igt@i915_pm_rpm@cursor-dpms.html
    - shard-iclb:         [PASS][24] -> [SKIP][25] ([i915#1316])
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb5/igt@i915_pm_rpm@cursor-dpms.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb7/igt@i915_pm_rpm@cursor-dpms.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
    - shard-kbl:          [PASS][26] -> [FAIL][27] ([i915#54] / [i915#93] / [i915#95])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl6/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x21-random:
    - shard-glk:          [PASS][28] -> [FAIL][29] ([i915#54])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk4/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk3/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html
    - shard-apl:          [PASS][30] -> [FAIL][31] ([i915#54]) +1 similar issue
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl1/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl4/igt@kms_cursor_crc@pipe-b-cursor-64x21-random.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen:
    - shard-kbl:          [PASS][32] -> [FAIL][33] ([i915#54]) +1 similar issue
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl6/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
    - shard-glk:          [PASS][34] -> [FAIL][35] ([i915#72])
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk5/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled:
    - shard-glk:          [PASS][36] -> [FAIL][37] ([i915#52] / [i915#54]) +3 similar issues
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled.html

  * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled:
    - shard-glk:          [PASS][38] -> [FAIL][39] ([i915#177] / [i915#52] / [i915#54])
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk4/igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk8/igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled.html

  * igt@kms_flip@flip-vs-suspend:
    - shard-kbl:          [PASS][40] -> [INCOMPLETE][41] ([i915#155] / [i915#600])
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl3/igt@kms_flip@flip-vs-suspend.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@kms_flip@flip-vs-suspend.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [PASS][42] -> [DMESG-WARN][43] ([i915#180])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite:
    - shard-glk:          [PASS][44] -> [FAIL][45] ([i915#49])
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite.html

  * igt@kms_psr@psr2_basic:
    - shard-iclb:         [PASS][46] -> [SKIP][47] ([fdo#109441]) +1 similar issue
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb2/igt@kms_psr@psr2_basic.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb7/igt@kms_psr@psr2_basic.html

  
#### Possible fixes ####

  * igt@gem_ctx_persistence@close-replace-race:
    - shard-tglb:         [INCOMPLETE][48] ([i915#1492]) -> [PASS][49]
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-tglb2/igt@gem_ctx_persistence@close-replace-race.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb8/igt@gem_ctx_persistence@close-replace-race.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [SKIP][50] ([fdo#110854]) -> [PASS][51]
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb7/igt@gem_exec_balancer@smoke.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_parallel@vcs1-fds:
    - shard-iclb:         [SKIP][52] ([fdo#112080]) -> [PASS][53] +8 similar issues
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb3/igt@gem_exec_parallel@vcs1-fds.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb4/igt@gem_exec_parallel@vcs1-fds.html

  * igt@gem_exec_schedule@implicit-read-write-bsd1:
    - shard-iclb:         [SKIP][54] ([fdo#109276] / [i915#677]) -> [PASS][55] +1 similar issue
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb8/igt@gem_exec_schedule@implicit-read-write-bsd1.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@gem_exec_schedule@implicit-read-write-bsd1.html

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
    - shard-iclb:         [SKIP][56] ([i915#677]) -> [PASS][57]
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb4/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb3/igt@gem_exec_schedule@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@wide-bsd:
    - shard-iclb:         [SKIP][58] ([fdo#112146]) -> [PASS][59] +3 similar issues
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb1/igt@gem_exec_schedule@wide-bsd.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb6/igt@gem_exec_schedule@wide-bsd.html

  * igt@gen9_exec_parse@allowed-all:
    - shard-apl:          [DMESG-WARN][60] ([i915#716]) -> [PASS][61]
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl1/igt@gen9_exec_parse@allowed-all.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@gen9_exec_parse@allowed-all.html

  * igt@i915_pm_rpm@gem-idle:
    - shard-iclb:         [SKIP][62] ([i915#1316]) -> [PASS][63] +1 similar issue
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb2/igt@i915_pm_rpm@gem-idle.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb1/igt@i915_pm_rpm@gem-idle.html
    - shard-glk:          [SKIP][64] ([fdo#109271]) -> [PASS][65] +1 similar issue
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk6/igt@i915_pm_rpm@gem-idle.html
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk3/igt@i915_pm_rpm@gem-idle.html
    - shard-tglb:         [SKIP][66] ([i915#1316]) -> [PASS][67] +1 similar issue
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-tglb3/igt@i915_pm_rpm@gem-idle.html
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb2/igt@i915_pm_rpm@gem-idle.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
    - shard-hsw:          [SKIP][68] ([fdo#109271]) -> [PASS][69] +1 similar issue
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-hsw6/igt@i915_pm_rpm@system-suspend-execbuf.html
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw8/igt@i915_pm_rpm@system-suspend-execbuf.html

  * igt@kms_draw_crc@draw-method-rgb565-render-untiled:
    - shard-glk:          [FAIL][70] ([i915#52] / [i915#54]) -> [PASS][71] +6 similar issues
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk7/igt@kms_draw_crc@draw-method-rgb565-render-untiled.html
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk1/igt@kms_draw_crc@draw-method-rgb565-render-untiled.html

  * igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-untiled:
    - shard-kbl:          [FAIL][72] ([fdo#108145] / [i915#177] / [i915#52] / [i915#54] / [i915#93] / [i915#95]) -> [PASS][73]
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl7/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-untiled.html
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl7/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-untiled.html
    - shard-apl:          [FAIL][74] ([fdo#108145] / [i915#52] / [i915#54] / [i915#95]) -> [PASS][75]
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl2/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-untiled.html
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl7/igt@kms_draw_crc@draw-method-xrgb8888-mmap-wc-untiled.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-apl:          [DMESG-WARN][76] ([i915#180] / [i915#95]) -> [PASS][77]
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl6/igt@kms_fbcon_fbt@fbc-suspend.html
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl7/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - shard-kbl:          [FAIL][78] ([i915#53] / [i915#93] / [i915#95]) -> [PASS][79]
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
    - shard-apl:          [FAIL][80] ([i915#53] / [i915#95]) -> [PASS][81]
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
    - shard-apl:          [DMESG-WARN][82] ([i915#180]) -> [PASS][83] +1 similar issue
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
    - shard-kbl:          [DMESG-WARN][84] ([i915#180]) -> [PASS][85] +2 similar issues
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_cursor@pipe-a-viewport-size-64:
    - shard-kbl:          [FAIL][86] ([i915#93] / [i915#95]) -> [PASS][87] +1 similar issue
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-kbl7/igt@kms_plane_cursor@pipe-a-viewport-size-64.html
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@kms_plane_cursor@pipe-a-viewport-size-64.html

  * igt@kms_psr@psr2_suspend:
    - shard-iclb:         [SKIP][88] ([fdo#109441]) -> [PASS][89] +1 similar issue
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb6/igt@kms_psr@psr2_suspend.html
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@kms_psr@psr2_suspend.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][90] ([fdo#109276]) -> [PASS][91] +15 similar issues
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb6/igt@prime_vgem@fence-wait-bsd2.html
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb1/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup@gtt:
    - shard-hsw:          [DMESG-WARN][92] ([fdo#110789] / [i915#478]) -> [DMESG-WARN][93] ([i915#478])
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-hsw2/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup@gtt.html
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw2/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup@gtt.html

  * igt@gem_userptr_blits@sync-unmap-after-close:
    - shard-hsw:          [DMESG-WARN][94] ([fdo#110789] / [fdo#111870]) -> [DMESG-WARN][95] ([fdo#111870])
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-hsw2/igt@gem_userptr_blits@sync-unmap-after-close.html
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw2/igt@gem_userptr_blits@sync-unmap-after-close.html
    - shard-snb:          [DMESG-WARN][96] ([fdo#110789] / [fdo#111870] / [i915#478]) -> [DMESG-WARN][97] ([fdo#111870] / [i915#478])
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-snb5/igt@gem_userptr_blits@sync-unmap-after-close.html
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-snb5/igt@gem_userptr_blits@sync-unmap-after-close.html

  * igt@i915_pm_rpm@pc8-residency:
    - shard-snb:          [INCOMPLETE][98] ([i915#82]) -> [SKIP][99] ([fdo#109271])
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-snb4/igt@i915_pm_rpm@pc8-residency.html
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-snb5/igt@i915_pm_rpm@pc8-residency.html

  * igt@runner@aborted:
    - shard-apl:          ([FAIL][100], [FAIL][101]) ([fdo#103927] / [i915#716]) -> [FAIL][102] ([fdo#103927])
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl1/igt@runner@aborted.html
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl6/igt@runner@aborted.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@runner@aborted.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#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109305]: https://bugs.freedesktop.org/show_bug.cgi?id=109305
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [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#1316]: https://gitlab.freedesktop.org/drm/intel/issues/1316
  [i915#1492]: https://gitlab.freedesktop.org/drm/intel/issues/1492
  [i915#1526]: https://gitlab.freedesktop.org/drm/intel/issues/1526
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#177]: https://gitlab.freedesktop.org/drm/intel/issues/177
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#274]: https://gitlab.freedesktop.org/drm/intel/issues/274
  [i915#478]: https://gitlab.freedesktop.org/drm/intel/issues/478
  [i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
  [i915#53]: https://gitlab.freedesktop.org/drm/intel/issues/53
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#600]: https://gitlab.freedesktop.org/drm/intel/issues/600
  [i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72
  [i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
  [i915#93]: https://gitlab.freedesktop.org/drm/intel/issues/93
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


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

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


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5539 -> IGTPW_4362
  * Piglit: piglit_4509 -> None

  CI-20190529: 20190529
  CI_DRM_8198: a421a6390d4a76e4df310bfe9adb78dde7207249 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4362: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/index.html
  IGT_5539: e7aae12e37771a8b7796ba252574eb832a5839c3 @ 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_4362/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27  4:50 ` Dixit, Ashutosh
@ 2020-03-27 16:09   ` Lionel Landwerlin
  2020-03-27 19:03     ` Dixit, Ashutosh
  0 siblings, 1 reply; 18+ messages in thread
From: Lionel Landwerlin @ 2020-03-27 16:09 UTC (permalink / raw)
  To: Dixit, Ashutosh, igt-dev

On 27/03/2020 06:50, Dixit, Ashutosh wrote:
> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
>> diff --git a/tests/perf.c b/tests/perf.c
>> index 724f6f809..3dc757c3b 100644
>> --- a/tests/perf.c
>> +++ b/tests/perf.c
>> +static void test_polling_small_buf(void)
>> +{
> /snip/
>
>> +
>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
>> +}
>> +
> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?


Do we have any experiment showing them behaving differently?


-Lionel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27 16:09   ` Lionel Landwerlin
@ 2020-03-27 19:03     ` Dixit, Ashutosh
  2020-03-27 19:06       ` Lionel Landwerlin
  0 siblings, 1 reply; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-27 19:03 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: igt-dev

On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
>
> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
> > On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
> >> diff --git a/tests/perf.c b/tests/perf.c
> >> index 724f6f809..3dc757c3b 100644
> >> --- a/tests/perf.c
> >> +++ b/tests/perf.c
> >> +static void test_polling_small_buf(void)
> >> +{
> > /snip/
> >
> >> +
> >> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
> >> +}
> >> +
> > I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
>
>
> Do we have any experiment showing them behaving differently?

No I don't have any data, but considering that in previous stable versions
we can only read < 10% of the data, I think it should be ok to go down to
80%? So that we don't start getting unnecessary false alarms in CI, even
when the issue is fixed.
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27 19:03     ` Dixit, Ashutosh
@ 2020-03-27 19:06       ` Lionel Landwerlin
  2020-03-27 19:49         ` Dixit, Ashutosh
  0 siblings, 1 reply; 18+ messages in thread
From: Lionel Landwerlin @ 2020-03-27 19:06 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: igt-dev

On 27/03/2020 21:03, Dixit, Ashutosh wrote:
> On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
>> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
>>> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
>>>> diff --git a/tests/perf.c b/tests/perf.c
>>>> index 724f6f809..3dc757c3b 100644
>>>> --- a/tests/perf.c
>>>> +++ b/tests/perf.c
>>>> +static void test_polling_small_buf(void)
>>>> +{
>>> /snip/
>>>
>>>> +
>>>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
>>>> +}
>>>> +
>>> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
>>
>> Do we have any experiment showing them behaving differently?
> No I don't have any data, but considering that in previous stable versions
> we can only read < 10% of the data, I think it should be ok to go down to
> 80%? So that we don't start getting unnecessary false alarms in CI, even
> when the issue is fixed.

Okay, for the record I get somewhere between 93~95% of expected reports 
on KBLGT2.


-Lionel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27 19:06       ` Lionel Landwerlin
@ 2020-03-27 19:49         ` Dixit, Ashutosh
  2020-03-31  6:06           ` Dixit, Ashutosh
  0 siblings, 1 reply; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-27 19:49 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: igt-dev

On Fri, 27 Mar 2020 12:06:13 -0700, Lionel Landwerlin wrote:
>
> On 27/03/2020 21:03, Dixit, Ashutosh wrote:
> > On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
> >> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
> >>> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
> >>>> diff --git a/tests/perf.c b/tests/perf.c
> >>>> index 724f6f809..3dc757c3b 100644
> >>>> --- a/tests/perf.c
> >>>> +++ b/tests/perf.c
> >>>> +static void test_polling_small_buf(void)
> >>>> +{
> >>> /snip/
> >>>
> >>>> +
> >>>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
> >>>> +}
> >>>> +
> >>> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
> >>
> >> Do we have any experiment showing them behaving differently?
> > No I don't have any data, but considering that in previous stable versions
> > we can only read < 10% of the data, I think it should be ok to go down to
> > 80%? So that we don't start getting unnecessary false alarms in CI, even
> > when the issue is fixed.
>
> Okay, for the record I get somewhere between 93~95% of expected reports on
> KBLGT2.

Yes I tried it and saw that. I already gave a R-b so we could probably
merge the patch after making that change (0.2 instead of 0.1 above), or do
you want me to post a new version with the change? Thanks!
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27  4:42 [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Ashutosh Dixit
                   ` (2 preceding siblings ...)
  2020-03-27 15:19 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
@ 2020-03-27 20:56 ` Umesh Nerlige Ramappa
  2020-03-27 22:02   ` Dixit, Ashutosh
  3 siblings, 1 reply; 18+ messages in thread
From: Umesh Nerlige Ramappa @ 2020-03-27 20:56 UTC (permalink / raw)
  To: Ashutosh Dixit; +Cc: igt-dev

On Thu, Mar 26, 2020 at 09:42:50PM -0700, Ashutosh Dixit wrote:
>Add a test for OA data non-blocking reads using buffers smaller than
>the available data. This test would fail for perf revisions < 5
>because poll would block even when data was available. Therefore the
>amount of data read was limited by the buffer size and the timer
>interval and it was impossible to read all available data. This issue
>is fixed in perf revision 5.
>
>v2: Complete rewrite, make test fail on existing kernels (Lionel)
>
>Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
>Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>---
> tests/perf.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
>diff --git a/tests/perf.c b/tests/perf.c
>index 724f6f809..3dc757c3b 100644
>--- a/tests/perf.c
>+++ b/tests/perf.c
>@@ -2265,6 +2265,71 @@ test_polling(void)
> 	__perf_close(stream_fd);
> }
>
>+static void test_polling_small_buf(void)
>+{
>+	int oa_exponent = max_oa_exponent_for_period_lte(40 * 1000); /* 40us */
>+	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,
>+	};
>+	struct drm_i915_perf_open_param param = {
>+		.flags = I915_PERF_FLAG_FD_CLOEXEC |
>+			I915_PERF_FLAG_DISABLED |
>+			I915_PERF_FLAG_FD_NONBLOCK,
>+		.num_properties = NUM_PROPERTIES(properties),
>+		.properties_ptr = to_user_pointer(properties),
>+	};
>+	uint32_t test_duration = 80 * 1000 * 1000;
>+	int sample_size = (sizeof(struct drm_i915_perf_record_header) +
>+				get_oa_format(test_set->perf_oa_format).size);
>+	int n_expected_reports = test_duration / oa_exponent_to_ns(oa_exponent);
>+	int n_expect_read_bytes = n_expected_reports * sample_size;
>+	uint8_t buf[1024];
>+	int n_bytes_read = 0;
>+	uint32_t n_polls = 0;
>+	struct timespec ts = {};
>+
>+	stream_fd = __perf_open(drm_fd, &param, true /* prevent_pm */);
>+	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
>+
>+	igt_nsec_elapsed(&ts);
>+
>+	while (igt_nsec_elapsed(&ts) < test_duration) {
>+		struct timespec poll_wait = {
>+			.tv_sec = 0,
>+			.tv_nsec = (test_duration - igt_nsec_elapsed(&ts)),
>+		};
>+		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
>+		int ret;
>+
>+		ret = ppoll(&pollfd, 1, &poll_wait, NULL);

when poll_wait reaches a value less than the default hrtimer poll 
period, poll will start timing out. I think the timeout will itself not 
set the POLLIN event, so that many reports will never be read.

Lionel,

the expected reports calculated here (and in other igt tests) do not 
take context switch reports into account. Do you think we can run into a 
situation where our calculations may go wrong due to large number of 
context switches? thoughts?

Thanks,
Umesh

>+
>+		if (pollfd.revents & POLLIN) {
>+			ret = read(stream_fd, buf, sizeof(buf));
>+			if (ret >= 0)
>+				n_bytes_read += ret;
>+		}
>+
>+		n_polls++;
>+
>+		igt_debug("Elapsed=%lu wait=%lu\n", igt_nsec_elapsed(&ts), poll_wait.tv_nsec);
>+	}
>+
>+	igt_info("Read %d expected %d (%.2f%% of the expected number), polls=%u\n",
>+		  n_bytes_read, n_expect_read_bytes,
>+		  n_bytes_read * 100.0f / n_expect_read_bytes,
>+		  n_polls);
>+
>+	__perf_close(stream_fd);
>+
>+	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
>+}
>+
> static int
> num_valid_reports_captured(struct drm_i915_perf_open_param *param,
> 			   int64_t *duration_ns)
>@@ -4676,6 +4741,10 @@ igt_main
> 	igt_subtest("polling")
> 		test_polling();
>
>+	igt_describe("Test polled read with buffer size smaller than available data");
>+	igt_subtest("polling-small-buf")
>+		test_polling_small_buf();
>+
> 	igt_subtest("short-reads")
> 		test_short_reads();
>
>-- 
>2.25.2
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27 20:56 ` [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Umesh Nerlige Ramappa
@ 2020-03-27 22:02   ` Dixit, Ashutosh
  0 siblings, 0 replies; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-27 22:02 UTC (permalink / raw)
  To: Umesh Nerlige Ramappa; +Cc: igt-dev

On Fri, 27 Mar 2020 13:56:42 -0700, Umesh Nerlige Ramappa wrote:
>
> On Thu, Mar 26, 2020 at 09:42:50PM -0700, Ashutosh Dixit wrote:
> > Add a test for OA data non-blocking reads using buffers smaller than
> > the available data. This test would fail for perf revisions < 5
> > because poll would block even when data was available. Therefore the
> > amount of data read was limited by the buffer size and the timer
> > interval and it was impossible to read all available data. This issue
> > is fixed in perf revision 5.
> >
> > v2: Complete rewrite, make test fail on existing kernels (Lionel)

/snip/

> > +	while (igt_nsec_elapsed(&ts) < test_duration) {
> > +		struct timespec poll_wait = {
> > +			.tv_sec = 0,
> > +			.tv_nsec = (test_duration - igt_nsec_elapsed(&ts)),
> > +		};
> > +		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
> > +		int ret;
> > +
> > +		ret = ppoll(&pollfd, 1, &poll_wait, NULL);
>
> when poll_wait reaches a value less than the default hrtimer poll period,
> poll will start timing out. I think the timeout will itself not set the
> POLLIN event, so that many reports will never be read.

Actually, poll timing out will just run in the loop running faster and
faster, so it will be busy spinning but will read data only when the timer
has fired and updated the tail pointer. So I think all reports will still
be read.

But that's a good point, what is the purpose of the timeout anyway? Why not
just have the poll unblock off the 5 ms timer? I will post a v3 with just
an infinite timeout and reducing data match requirement to 80%.

> the expected reports calculated here (and in other igt tests) do not take
> context switch reports into account. Do you think we can run into a
> situation where our calculations may go wrong due to large number of
> context switches? thoughts?

Well for IGT's mostly there is nothing else except the IGT running so maybe
it's ok? So what data is being collected when the GPU is idle, just some
periodic data?

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-27 19:49         ` Dixit, Ashutosh
@ 2020-03-31  6:06           ` Dixit, Ashutosh
  2020-03-31  7:36             ` Lionel Landwerlin
  0 siblings, 1 reply; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-31  6:06 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: igt-dev

On Fri, 27 Mar 2020 12:49:22 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 27 Mar 2020 12:06:13 -0700, Lionel Landwerlin wrote:
> >
> > On 27/03/2020 21:03, Dixit, Ashutosh wrote:
> > > On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
> > >> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
> > >>> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
> > >>>> diff --git a/tests/perf.c b/tests/perf.c
> > >>>> index 724f6f809..3dc757c3b 100644
> > >>>> --- a/tests/perf.c
> > >>>> +++ b/tests/perf.c
> > >>>> +static void test_polling_small_buf(void)
> > >>>> +{
> > >>> /snip/
> > >>>
> > >>>> +
> > >>>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
> > >>>> +}
> > >>>> +
> > >>> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
> > >>
> > >> Do we have any experiment showing them behaving differently?
> > > No I don't have any data, but considering that in previous stable versions
> > > we can only read < 10% of the data, I think it should be ok to go down to
> > > 80%? So that we don't start getting unnecessary false alarms in CI, even
> > > when the issue is fixed.
> >
> > Okay, for the record I get somewhere between 93~95% of expected reports on
> > KBLGT2.
>
> Yes I tried it and saw that. I already gave a R-b so we could probably
> merge the patch after making that change (0.2 instead of 0.1 above), or do
> you want me to post a new version with the change? Thanks!

Actually there has been some change in the kernel, earlier like you I was
also getting around 94% with a 1 KB buffer, now I am getting about
87%. I am getting 94% with a 1 MB buffer. Does the amount of expected data
in the test need to be modified? I can try to bisect tomorrow and see what
has done this, unless you already know. Thanks!
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-31  6:06           ` Dixit, Ashutosh
@ 2020-03-31  7:36             ` Lionel Landwerlin
  2020-03-31  7:48               ` Dixit, Ashutosh
  0 siblings, 1 reply; 18+ messages in thread
From: Lionel Landwerlin @ 2020-03-31  7:36 UTC (permalink / raw)
  To: Dixit, Ashutosh; +Cc: igt-dev

On 31/03/2020 09:06, Dixit, Ashutosh wrote:
> On Fri, 27 Mar 2020 12:49:22 -0700, Dixit, Ashutosh wrote:
>> On Fri, 27 Mar 2020 12:06:13 -0700, Lionel Landwerlin wrote:
>>> On 27/03/2020 21:03, Dixit, Ashutosh wrote:
>>>> On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
>>>>> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
>>>>>> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
>>>>>>> diff --git a/tests/perf.c b/tests/perf.c
>>>>>>> index 724f6f809..3dc757c3b 100644
>>>>>>> --- a/tests/perf.c
>>>>>>> +++ b/tests/perf.c
>>>>>>> +static void test_polling_small_buf(void)
>>>>>>> +{
>>>>>> /snip/
>>>>>>
>>>>>>> +
>>>>>>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
>>>>>>> +}
>>>>>>> +
>>>>>> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
>>>>> Do we have any experiment showing them behaving differently?
>>>> No I don't have any data, but considering that in previous stable versions
>>>> we can only read < 10% of the data, I think it should be ok to go down to
>>>> 80%? So that we don't start getting unnecessary false alarms in CI, even
>>>> when the issue is fixed.
>>> Okay, for the record I get somewhere between 93~95% of expected reports on
>>> KBLGT2.
>> Yes I tried it and saw that. I already gave a R-b so we could probably
>> merge the patch after making that change (0.2 instead of 0.1 above), or do
>> you want me to post a new version with the change? Thanks!
> Actually there has been some change in the kernel, earlier like you I was
> also getting around 94% with a 1 KB buffer, now I am getting about
> 87%. I am getting 94% with a 1 MB buffer. Does the amount of expected data
> in the test need to be modified? I can try to bisect tomorrow and see what
> has done this, unless you already know. Thanks!

Ah, that's probably the read() bug you're fixing...

Are you running with the kernel patch : "drm/i915/perf: Do not clear 
pollin for small user read buffers" ?


-Lionel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-31  7:36             ` Lionel Landwerlin
@ 2020-03-31  7:48               ` Dixit, Ashutosh
  2020-04-03  1:19                 ` Dixit, Ashutosh
  0 siblings, 1 reply; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-31  7:48 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: igt-dev

On Tue, 31 Mar 2020 00:36:54 -0700, Lionel Landwerlin wrote:
>
> On 31/03/2020 09:06, Dixit, Ashutosh wrote:
> > On Fri, 27 Mar 2020 12:49:22 -0700, Dixit, Ashutosh wrote:
> >> On Fri, 27 Mar 2020 12:06:13 -0700, Lionel Landwerlin wrote:
> >>> On 27/03/2020 21:03, Dixit, Ashutosh wrote:
> >>>> On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
> >>>>> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
> >>>>>> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
> >>>>>>> diff --git a/tests/perf.c b/tests/perf.c
> >>>>>>> index 724f6f809..3dc757c3b 100644
> >>>>>>> --- a/tests/perf.c
> >>>>>>> +++ b/tests/perf.c
> >>>>>>> +static void test_polling_small_buf(void)
> >>>>>>> +{
> >>>>>> /snip/
> >>>>>>
> >>>>>>> +
> >>>>>>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
> >>>>>>> +}
> >>>>>>> +
> >>>>>> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
> >>>>> Do we have any experiment showing them behaving differently?
> >>>> No I don't have any data, but considering that in previous stable versions
> >>>> we can only read < 10% of the data, I think it should be ok to go down to
> >>>> 80%? So that we don't start getting unnecessary false alarms in CI, even
> >>>> when the issue is fixed.
> >>> Okay, for the record I get somewhere between 93~95% of expected reports on
> >>> KBLGT2.
> >> Yes I tried it and saw that. I already gave a R-b so we could probably
> >> merge the patch after making that change (0.2 instead of 0.1 above), or do
> >> you want me to post a new version with the change? Thanks!
> > Actually there has been some change in the kernel, earlier like you I was
> > also getting around 94% with a 1 KB buffer, now I am getting about
> > 87%. I am getting 94% with a 1 MB buffer. Does the amount of expected data
> > in the test need to be modified? I can try to bisect tomorrow and see what
> > has done this, unless you already know. Thanks!
>
> Ah, that's probably the read() bug you're fixing...
>
> Are you running with the kernel patch : "drm/i915/perf: Do not clear pollin
> for small user read buffers" ?

Yes, I was just testing the patch before posting it and I chanced on
this. Thanks!
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-31  7:48               ` Dixit, Ashutosh
@ 2020-04-03  1:19                 ` Dixit, Ashutosh
  0 siblings, 0 replies; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-04-03  1:19 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: igt-dev

On Tue, 31 Mar 2020 00:48:45 -0700, Dixit, Ashutosh wrote:
>
> On Tue, 31 Mar 2020 00:36:54 -0700, Lionel Landwerlin wrote:
> >
> > On 31/03/2020 09:06, Dixit, Ashutosh wrote:
> > > On Fri, 27 Mar 2020 12:49:22 -0700, Dixit, Ashutosh wrote:
> > >> On Fri, 27 Mar 2020 12:06:13 -0700, Lionel Landwerlin wrote:
> > >>> On 27/03/2020 21:03, Dixit, Ashutosh wrote:
> > >>>> On Fri, 27 Mar 2020 09:09:41 -0700, Lionel Landwerlin wrote:
> > >>>>> On 27/03/2020 06:50, Dixit, Ashutosh wrote:
> > >>>>>> On Thu, 26 Mar 2020 21:42:50 -0700, Ashutosh Dixit wrote:
> > >>>>>>> diff --git a/tests/perf.c b/tests/perf.c
> > >>>>>>> index 724f6f809..3dc757c3b 100644
> > >>>>>>> --- a/tests/perf.c
> > >>>>>>> +++ b/tests/perf.c
> > >>>>>>> +static void test_polling_small_buf(void)
> > >>>>>>> +{
> > >>>>>> /snip/
> > >>>>>>
> > >>>>>>> +
> > >>>>>>> +	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.10 * n_expect_read_bytes));
> > >>>>>>> +}
> > >>>>>>> +
> > >>>>>> I'd be wary of a 90% match on slow platforms like Atom? Maybe 80% is safer?
> > >>>>> Do we have any experiment showing them behaving differently?
> > >>>> No I don't have any data, but considering that in previous stable versions
> > >>>> we can only read < 10% of the data, I think it should be ok to go down to
> > >>>> 80%? So that we don't start getting unnecessary false alarms in CI, even
> > >>>> when the issue is fixed.
> > >>> Okay, for the record I get somewhere between 93~95% of expected reports on
> > >>> KBLGT2.
> > >> Yes I tried it and saw that. I already gave a R-b so we could probably
> > >> merge the patch after making that change (0.2 instead of 0.1 above), or do
> > >> you want me to post a new version with the change? Thanks!
> > >
> > > Actually there has been some change in the kernel, earlier like you I was
> > > also getting around 94% with a 1 KB buffer, now I am getting about
> > > 87%. I am getting 94% with a 1 MB buffer. Does the amount of expected data
> > > in the test need to be modified? I can try to bisect tomorrow and see what
> > > has done this, unless you already know. Thanks!

I haven't been able to easily narrow this down, I am not sure if it is
worth spending more time on it. However since v3 of the test only requires
a 80% match the test passes with kernel patch : "drm/i915/perf: Do not
clear pollin for small user read buffers" and will fail on prior/stable
kernels. Thanks!

> >
> > Ah, that's probably the read() bug you're fixing...
> >
> > Are you running with the kernel patch : "drm/i915/perf: Do not clear pollin
> > for small user read buffers" ?
>
> Yes, I was just testing the patch before posting it and I chanced on
> this. Thanks!

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
@ 2020-03-27 22:29 Ashutosh Dixit
  0 siblings, 0 replies; 18+ messages in thread
From: Ashutosh Dixit @ 2020-03-27 22:29 UTC (permalink / raw)
  To: igt-dev

Add a test for OA data non-blocking reads using buffers smaller than
the available data. This test would fail for perf revisions < 5
because poll would block even when data was available. Therefore the
amount of data read was limited by the buffer size and the timer
interval and it was impossible to read all available data. This issue
is fixed in perf revision 5.

v2: Complete rewrite, make test fail on existing kernels (Lionel)

v3: Use infinite ppoll timeout (Umesh)
    Increase mismatch tolerance to 20% (Ashutosh)

Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
---
 tests/perf.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index 442d89fbe..6c0b2ee7f 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -2284,6 +2284,65 @@ test_polling(uint64_t requested_oa_period, bool set_kernel_hrtimer, uint64_t ker
 	__perf_close(stream_fd);
 }
 
+static void test_polling_small_buf(void)
+{
+	int oa_exponent = max_oa_exponent_for_period_lte(40 * 1000); /* 40us */
+	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,
+	};
+	struct drm_i915_perf_open_param param = {
+		.flags = I915_PERF_FLAG_FD_CLOEXEC |
+			I915_PERF_FLAG_DISABLED |
+			I915_PERF_FLAG_FD_NONBLOCK,
+		.num_properties = NUM_PROPERTIES(properties),
+		.properties_ptr = to_user_pointer(properties),
+	};
+	uint32_t test_duration = 80 * 1000 * 1000;
+	int sample_size = (sizeof(struct drm_i915_perf_record_header) +
+				get_oa_format(test_set->perf_oa_format).size);
+	int n_expected_reports = test_duration / oa_exponent_to_ns(oa_exponent);
+	int n_expect_read_bytes = n_expected_reports * sample_size;
+	uint8_t buf[1024];
+	int n_bytes_read = 0;
+	uint32_t n_polls = 0;
+	struct timespec ts = {};
+
+	stream_fd = __perf_open(drm_fd, &param, true /* prevent_pm */);
+	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
+
+	igt_nsec_elapsed(&ts);
+
+	while (igt_nsec_elapsed(&ts) < test_duration) {
+		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
+		int ret;
+
+		ret = ppoll(&pollfd, 1, NULL, NULL);
+
+		if (pollfd.revents & POLLIN) {
+			ret = read(stream_fd, buf, sizeof(buf));
+			if (ret >= 0)
+				n_bytes_read += ret;
+		}
+
+		n_polls++;
+	}
+
+	igt_info("Read %d expected %d (%.2f%% of the expected number), polls=%u\n",
+		  n_bytes_read, n_expect_read_bytes,
+		  n_bytes_read * 100.0f / n_expect_read_bytes,
+		  n_polls);
+
+	__perf_close(stream_fd);
+
+	igt_assert(abs(n_expect_read_bytes - n_bytes_read) < (0.20 * n_expect_read_bytes));
+}
+
 static int
 num_valid_reports_captured(struct drm_i915_perf_open_param *param,
 			   int64_t *duration_ns)
@@ -4919,6 +4978,10 @@ igt_main
 			     2 * 1000 * 1000 /* default 2ms hrtimer */);
 	}
 
+	igt_describe("Test polled read with buffer size smaller than available data");
+	igt_subtest("polling-small-buf")
+		test_polling_small_buf();
+
 	igt_subtest("short-reads")
 		test_short_reads();
 
-- 
2.25.2

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

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-26  9:02 ` Lionel Landwerlin
@ 2020-03-27  4:08   ` Dixit, Ashutosh
  0 siblings, 0 replies; 18+ messages in thread
From: Dixit, Ashutosh @ 2020-03-27  4:08 UTC (permalink / raw)
  To: Lionel Landwerlin; +Cc: igt-dev

On Thu, 26 Mar 2020 02:02:40 -0700, Lionel Landwerlin wrote:
>
> On 26/03/2020 07:42, Ashutosh Dixit wrote:
> > Add a test for OA data non-blocking reads using buffers smaller than
> > the available data. This test would fail for perf revisions < 5
> > because poll would block even when data was available. Therefore the
> > amount of data read was limited by the buffer size and the timer
> > interval and it was impossible to read all available data. This issue
> > is fixed in perf revision 5.
>
>
> There seems to be a fundamental issue with this test, it's supposed to
> test a broken behavior with revision < 5 but then avoid testing anything
> there ;)

It was guaranteed to fail, but I see your point, you are saying let if fail
for rev < 5 but then submit the kernel patch as a fix.

> I've modified this test a bit here :
> https://gitlab.freedesktop.org/llandwerlin/igt-gpu-tools/-/tree/for-ashutosh
>
> It's failing stable kernels.
>
> Increasing the size of the buffer to 1Mb make the test pass.

I like it, I didn't know you could estimate the amount of OA data. I will
clean it up, test and post it as v2.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
  2020-03-26  5:42 Ashutosh Dixit
@ 2020-03-26  9:02 ` Lionel Landwerlin
  2020-03-27  4:08   ` Dixit, Ashutosh
  0 siblings, 1 reply; 18+ messages in thread
From: Lionel Landwerlin @ 2020-03-26  9:02 UTC (permalink / raw)
  To: Ashutosh Dixit, igt-dev

On 26/03/2020 07:42, Ashutosh Dixit wrote:
> Add a test for OA data non-blocking reads using buffers smaller than
> the available data. This test would fail for perf revisions < 5
> because poll would block even when data was available. Therefore the
> amount of data read was limited by the buffer size and the timer
> interval and it was impossible to read all available data. This issue
> is fixed in perf revision 5.


There seems to be a fundamental issue with this test, it's supposed to 
test a broken behavior with revision < 5 but then avoid testing anything 
there ;)


I've modified this test a bit here : 
https://gitlab.freedesktop.org/llandwerlin/igt-gpu-tools/-/tree/for-ashutosh

It's failing stable kernels.


Increasing the size of the buffer to 1Mb make the test pass.


-Lionel


>
> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Signed-off--by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> ---
>   tests/perf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 81 insertions(+)
>
> diff --git a/tests/perf.c b/tests/perf.c
> index 724f6f809..41e3b4478 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -2265,6 +2265,81 @@ test_polling(void)
>   	__perf_close(stream_fd);
>   }
>   
> +static void test_polling_small_buf(void)
> +{
> +	int oa_exponent = max_oa_exponent_for_period_lte(10 * 1000 * 1000); /* 10ms */
> +	/* Use a large value for the timer for a large amout of data to accumulate */
> +	uint64_t kernel_hrtimer = 400 * 1000 * 1000; /* 400 ms */
> +	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,
> +
> +		/* Kernel configuration (optional) */
> +		DRM_I915_PERF_PROP_POLL_OA_PERIOD, 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 = NUM_PROPERTIES(properties),
> +		.properties_ptr = to_user_pointer(properties),
> +	};
> +	uint8_t buf[1024 * 1024];
> +	int ret, iterl = 0, iters = 0, large = 0, small = 0;
> +	struct timespec tsl = {}, tss = {};
> +
> +	stream_fd = __perf_open(drm_fd, &param, true /* prevent_pm */);
> +	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
> +
> +	/* First do non blocking reads for 4 seconds using 1 MB buffer */
> +	igt_nsec_elapsed(&tsl);
> +	igt_until_timeout(4) {
> +		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
> +
> +		ret = poll(&pollfd, 1, -1);
> +		igt_assert_eq(ret, 1);
> +		igt_assert(pollfd.revents & POLLIN);
> +
> +		ret = read(stream_fd, buf, sizeof(buf));
> +		igt_assert(ret > 0);
> +		large += ret;
> +		iterl++;
> +	}
> +	igt_debug("Read %d B in %d iterations in %ld ns using 1 MB buffer\n",
> +		  large, iterl, igt_nsec_elapsed(&tsl));
> +
> +	/* Now repeat the read with a 4 KB buffer */
> +	igt_nsec_elapsed(&tss);
> +	igt_until_timeout(4) {
> +		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
> +
> +		ret = poll(&pollfd, 1, -1);
> +		igt_assert_eq(ret, 1);
> +		igt_assert(pollfd.revents & POLLIN);
> +
> +		ret = read(stream_fd, buf, 4096);
> +		igt_assert(ret > 0);
> +		small += ret;
> +		iters++;
> +	}
> +	igt_debug("Read %d B in %d iterations in %ld ns using 4 KB buffer\n",
> +		  small, iters, igt_nsec_elapsed(&tss));
> +
> +	__perf_close(stream_fd);
> +
> +	/* Check that data read using the two methods is within 20% of each
> +	 * other. Differences between the two cases is due to timing coupled
> +	 * with granularity of the data reads, but they are still expected to be
> +	 * "close".
> +	 */
> +	igt_assert(abs(large - small) * 100 / ((large + small) / 2) < 20);
> +}
> +
>   static int
>   num_valid_reports_captured(struct drm_i915_perf_open_param *param,
>   			   int64_t *duration_ns)
> @@ -4676,6 +4751,12 @@ igt_main
>   	igt_subtest("polling")
>   		test_polling();
>   
> +	igt_describe("Test polled read with buffer size smaller than available data");
> +	igt_subtest("polling-small-buf") {
> +		igt_require(i915_perf_revision(drm_fd) >= 5);
> +		test_polling_small_buf();
> +	}
> +
>   	igt_subtest("short-reads")
>   		test_short_reads();
>   


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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers
@ 2020-03-26  5:42 Ashutosh Dixit
  2020-03-26  9:02 ` Lionel Landwerlin
  0 siblings, 1 reply; 18+ messages in thread
From: Ashutosh Dixit @ 2020-03-26  5:42 UTC (permalink / raw)
  To: igt-dev

Add a test for OA data non-blocking reads using buffers smaller than
the available data. This test would fail for perf revisions < 5
because poll would block even when data was available. Therefore the
amount of data read was limited by the buffer size and the timer
interval and it was impossible to read all available data. This issue
is fixed in perf revision 5.

Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off--by: Ashutosh Dixit <ashutosh.dixit@intel.com>
---
 tests/perf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/tests/perf.c b/tests/perf.c
index 724f6f809..41e3b4478 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -2265,6 +2265,81 @@ test_polling(void)
 	__perf_close(stream_fd);
 }
 
+static void test_polling_small_buf(void)
+{
+	int oa_exponent = max_oa_exponent_for_period_lte(10 * 1000 * 1000); /* 10ms */
+	/* Use a large value for the timer for a large amout of data to accumulate */
+	uint64_t kernel_hrtimer = 400 * 1000 * 1000; /* 400 ms */
+	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,
+
+		/* Kernel configuration (optional) */
+		DRM_I915_PERF_PROP_POLL_OA_PERIOD, 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 = NUM_PROPERTIES(properties),
+		.properties_ptr = to_user_pointer(properties),
+	};
+	uint8_t buf[1024 * 1024];
+	int ret, iterl = 0, iters = 0, large = 0, small = 0;
+	struct timespec tsl = {}, tss = {};
+
+	stream_fd = __perf_open(drm_fd, &param, true /* prevent_pm */);
+	do_ioctl(stream_fd, I915_PERF_IOCTL_ENABLE, 0);
+
+	/* First do non blocking reads for 4 seconds using 1 MB buffer */
+	igt_nsec_elapsed(&tsl);
+	igt_until_timeout(4) {
+		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
+
+		ret = poll(&pollfd, 1, -1);
+		igt_assert_eq(ret, 1);
+		igt_assert(pollfd.revents & POLLIN);
+
+		ret = read(stream_fd, buf, sizeof(buf));
+		igt_assert(ret > 0);
+		large += ret;
+		iterl++;
+	}
+	igt_debug("Read %d B in %d iterations in %ld ns using 1 MB buffer\n",
+		  large, iterl, igt_nsec_elapsed(&tsl));
+
+	/* Now repeat the read with a 4 KB buffer */
+	igt_nsec_elapsed(&tss);
+	igt_until_timeout(4) {
+		struct pollfd pollfd = { .fd = stream_fd, .events = POLLIN };
+
+		ret = poll(&pollfd, 1, -1);
+		igt_assert_eq(ret, 1);
+		igt_assert(pollfd.revents & POLLIN);
+
+		ret = read(stream_fd, buf, 4096);
+		igt_assert(ret > 0);
+		small += ret;
+		iters++;
+	}
+	igt_debug("Read %d B in %d iterations in %ld ns using 4 KB buffer\n",
+		  small, iters, igt_nsec_elapsed(&tss));
+
+	__perf_close(stream_fd);
+
+	/* Check that data read using the two methods is within 20% of each
+	 * other. Differences between the two cases is due to timing coupled
+	 * with granularity of the data reads, but they are still expected to be
+	 * "close".
+	 */
+	igt_assert(abs(large - small) * 100 / ((large + small) / 2) < 20);
+}
+
 static int
 num_valid_reports_captured(struct drm_i915_perf_open_param *param,
 			   int64_t *duration_ns)
@@ -4676,6 +4751,12 @@ igt_main
 	igt_subtest("polling")
 		test_polling();
 
+	igt_describe("Test polled read with buffer size smaller than available data");
+	igt_subtest("polling-small-buf") {
+		igt_require(i915_perf_revision(drm_fd) >= 5);
+		test_polling_small_buf();
+	}
+
 	igt_subtest("short-reads")
 		test_short_reads();
 
-- 
2.25.2

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

^ permalink raw reply related	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2020-04-03  1:19 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-27  4:42 [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Ashutosh Dixit
2020-03-27  4:50 ` Dixit, Ashutosh
2020-03-27 16:09   ` Lionel Landwerlin
2020-03-27 19:03     ` Dixit, Ashutosh
2020-03-27 19:06       ` Lionel Landwerlin
2020-03-27 19:49         ` Dixit, Ashutosh
2020-03-31  6:06           ` Dixit, Ashutosh
2020-03-31  7:36             ` Lionel Landwerlin
2020-03-31  7:48               ` Dixit, Ashutosh
2020-04-03  1:19                 ` Dixit, Ashutosh
2020-03-27  5:23 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2) Patchwork
2020-03-27 15:19 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2020-03-27 20:56 ` [igt-dev] [PATCH i-g-t] tests/perf: add a test for OA data polling reads using "small" buffers Umesh Nerlige Ramappa
2020-03-27 22:02   ` Dixit, Ashutosh
  -- strict thread matches above, loose matches on Subject: below --
2020-03-27 22:29 Ashutosh Dixit
2020-03-26  5:42 Ashutosh Dixit
2020-03-26  9:02 ` Lionel Landwerlin
2020-03-27  4:08   ` Dixit, Ashutosh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.