tests/perf: add a test for OA data polling reads using "small" buffers
PATCH 1/1 tests/perf: add a test for OA data polling reads using "small" buffers
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)
--- tests/perf.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)
tests/perf.c +69 -0
@@ -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, ¶m, 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 ();
Signature · 6 lines
2.25.2 _______________________________________________ igt-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/igt-dev
tests/perf.c test_polling(void) · line 2269
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{
/snip/
tests/perf.c test_polling(void) · line 2332
Quoted 4 lines
tests/perf.c +4
-0+ +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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 9 lines · Ashutosh
tests/perf.c test_polling(void) · line 2269
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
Quoted 5 lines
tests/perf.c test_polling(void) · line 2332
Quoted 4 lines
tests/perf.c +4
-0+ +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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 11 lines · Lionel Landwerlin
Quoted 9 lines · Ashutosh
tests/perf.c test_polling(void) · line 2269
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
Quoted 8 lines
Quoted 5 lines
tests/perf.c test_polling(void) · line 2332
Quoted 4 lines
tests/perf.c +4
-0+ +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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 17 lines · Ashutosh
Quoted 16 lines · Lionel Landwerlin
Quoted 14 lines · Ashutosh
tests/perf.c test_polling(void) · line 2269
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
tests/perf.c test_polling(void) · line 2332
Quoted 4 lines
tests/perf.c +4
-0+ +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?
Quoted 5 lines
Quoted 1 line
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 19 lines · Lionel Landwerlin
Quoted 17 lines · Ashutosh
Quoted 16 lines · Lionel Landwerlin
Quoted 14 lines · Ashutosh
tests/perf.c test_polling(void) · line 2269
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
tests/perf.c test_polling(void) · line 2332
Quoted 4 lines
tests/perf.c +4
-0+ +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?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 27 lines · Ashutosh
Quoted 25 lines · Lionel Landwerlin
Quoted 22 lines · Ashutosh
Quoted 10 lines · Lionel Landwerlin
Quoted 9 lines · Ashutosh
tests/perf.c test_polling(void) · line 2269
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
Quoted 7 lines
Quoted 5 lines
tests/perf.c test_polling(void) · line 2332
Quoted 4 lines
tests/perf.c +4
-0+ +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.
Quoted 6 lines
Quoted 2 lines
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 26 lines · Ashutosh
Quoted 25 lines · Ashutosh
Quoted 24 lines · Lionel Landwerlin
Quoted 16 lines · Ashutosh
Quoted 15 lines · Lionel Landwerlin
Quoted 14 lines · Ashutosh
tests/perf.c
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
tests/perf.c
Quoted 4 lines
tests/perf.c +4
-0+ +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?
Quoted 5 lines
Quoted 1 line
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.
Quoted 8 lines
Quoted 3 lines
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 37 lines · Lionel Landwerlin
Quoted 26 lines · Ashutosh
Quoted 25 lines · Ashutosh
Quoted 24 lines · Lionel Landwerlin
Quoted 16 lines · Ashutosh
Quoted 15 lines · Lionel Landwerlin
Quoted 14 lines · Ashutosh
tests/perf.c
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
tests/perf.c
Quoted 4 lines
tests/perf.c +4
-0+ +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?
Quoted 5 lines
Quoted 1 line
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.
Quoted 8 lines
Quoted 3 lines
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!
Quoted 4 lines
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 34 lines · Ashutosh
Quoted 32 lines · Lionel Landwerlin
Quoted 30 lines · Ashutosh
Quoted 28 lines · Ashutosh
Quoted 17 lines · Lionel Landwerlin
Quoted 16 lines · Ashutosh
Quoted 15 lines · Lionel Landwerlin
Quoted 14 lines · Ashutosh
tests/perf.c
Quoted 6 lines · Ashutosh Dixit
tests/perf.c +2
-0+static void test_polling_small_buf (void ) +{/snip/
tests/perf.c
Quoted 4 lines
tests/perf.c +4
-0+ +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?
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
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!
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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!
Quoted 8 lines
Quoted 5 lines
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Patchwork
CI[igt-dev] ✓ Fi.CI.BAT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2)
In reply to Ashutosh Dixit== Series Details ==
== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Patchwork
CI[igt-dev] ✓ Fi.CI.IGT: success for tests/perf: add a test for OA data polling reads using "small" buffers (rev2)
In reply to Ashutosh Dixit== Series Details ==
== 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@[email protected]
- shard-tglb: NOTRUN -> [FAIL][2]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb1/igt@[email protected]
- shard-apl: NOTRUN -> [FAIL][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@[email protected]
- shard-kbl: NOTRUN -> [FAIL][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl6/igt@[email protected]
- shard-iclb: NOTRUN -> [FAIL][5]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb8/igt@[email protected]
#### 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@[email protected]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb6/igt@[email protected]
* 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@[email protected]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb8/igt@[email protected]
* 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@[email protected]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb1/igt@[email protected]
* 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@[email protected]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@[email protected]
* 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@[email protected]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-snb1/igt@[email protected]
* 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@[email protected]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw6/igt@[email protected]
- shard-glk: [PASS][22] -> [SKIP][23] ([fdo#109271])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-glk6/igt@[email protected]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk4/igt@[email protected]
- shard-iclb: [PASS][24] -> [SKIP][25] ([i915#1316])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-iclb5/igt@[email protected]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb7/igt@[email protected]
* 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@[email protected]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl2/igt@[email protected]
* 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@[email protected]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk3/igt@[email protected]
- 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@[email protected]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl4/igt@[email protected]
* 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@[email protected]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl6/igt@[email protected]
* 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@[email protected]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk8/igt@[email protected]
* 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@[email protected]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk7/igt@[email protected]
* 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@[email protected]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk8/igt@[email protected]
* 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@[email protected]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@[email protected]
* 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@[email protected]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@[email protected]
* 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@[email protected]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb8/igt@[email protected]
* 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@[email protected]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@[email protected]
* 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@[email protected]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb4/igt@[email protected]
* 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@[email protected]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb2/igt@[email protected]
* 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@[email protected]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb3/igt@[email protected]
* 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@[email protected]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb6/igt@[email protected]
* 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@[email protected]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@[email protected]
* 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@[email protected]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb1/igt@[email protected]
- 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@[email protected]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk3/igt@[email protected]
- 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@[email protected]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-tglb2/igt@[email protected]
* 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@[email protected]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw8/igt@[email protected]
* 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@[email protected]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-glk1/igt@[email protected]
* 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@[email protected]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl7/igt@[email protected]
- 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@[email protected]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl7/igt@[email protected]
* 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@[email protected]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl7/igt@[email protected]
* 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@[email protected]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@[email protected]
- 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@[email protected]
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl7/igt@[email protected]
* 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@[email protected]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@[email protected]
* 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@[email protected]
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@[email protected]
* 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@[email protected]
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-kbl3/igt@[email protected]
* 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@[email protected]
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-iclb1/igt@[email protected]
#### 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@[email protected]
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw2/igt@gem_userptr_blits@[email protected]
* 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@[email protected]
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-hsw2/igt@[email protected]
- 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@[email protected]
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-snb5/igt@[email protected]
* 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@[email protected]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-snb5/igt@[email protected]
* 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@[email protected]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8198/shard-apl6/igt@[email protected]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4362/shard-apl6/igt@[email protected]
{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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 58 lines · Ashutosh Dixit
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 <[email protected]>Reviewed-by Ashutosh Dixit <[email protected]>Signed-off-by Ashutosh Dixit <[email protected]>Signed-off-by Lionel Landwerlin <[email protected]>---
tests/perf.c| 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++1 file changed, 69 insertions(+)tests/perf.c +33
-0@@ -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, ¶m, true/* prevent_pm */ ); +do_ioctl (stream_fd,I915_PERF_IOCTL_ENABLE ,0 ); + +igt_nsec_elapsed (&ts);
tests/perf.c test_polling(void) · line 2310
Quoted 10 lines
tests/perf.c +10
-0+ +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
Quoted 39 lines
tests/perf.c +22
-0+ +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(structdrm_i915_perf_open_param*param,int64_t *duration_ns)tests/perf.c +4
-0@@ -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 ();Signature · 1 line
2.25.2
_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
Quoted 10 lines · Umesh Nerlige Ramappa
Quoted 8 lines · Ashutosh Dixit
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/
Quoted 5 lines
Quoted 5 lines
tests/perf.c +5
-0+while (igt_nsec_elapsed (&ts) < test_duration) { +struct timespec poll_wait = { + .tv_sec =0 , + .tv_nsec = (test_duration -igt_nsec_elapsed (&ts)), + };
Quoted 8 lines
tests/perf.c test_polling(void) · line 2310
Quoted 4 lines
tests/perf.c +4
-0+struct pollfd pollfd = { .fd = stream_fd, .events =POLLIN }; +int ret; + + ret =ppoll (&pollfd,1 , &poll_wait,NULL );when
poll_waitreaches 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%.
Quoted 4 lines
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev