All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 1/2] igt/perf_pmu: Aim for a fixed number of iterations for calibrating accuracy
Date: Thu, 9 Aug 2018 12:54:41 +0100	[thread overview]
Message-ID: <8257df1e-bf5d-7ba2-c423-12b98da696c2@linux.intel.com> (raw)
In-Reply-To: <20180808145945.26159-1-chris@chris-wilson.co.uk>


On 08/08/2018 15:59, Chris Wilson wrote:
> Our observation is that the systematic error is proportional to the
> number of iterations we perform; the suspicion is that it directly
> correlates with the number of sleeps. Reduce the number of iterations,
> to try and keep the error in check.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   tests/perf_pmu.c | 34 +++++++++++++++++++++-------------
>   1 file changed, 21 insertions(+), 13 deletions(-)
> 
> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> index 9a20abb6b..5a26d5272 100644
> --- a/tests/perf_pmu.c
> +++ b/tests/perf_pmu.c
> @@ -1521,14 +1521,13 @@ static void __rearm_spin_batch(igt_spin_t *spin)
>   
>   static void
>   accuracy(int gem_fd, const struct intel_execution_engine2 *e,
> -	 unsigned long target_busy_pct)
> +	 unsigned long target_busy_pct,
> +	 unsigned long target_iters)
>   {
> -	unsigned long busy_us = 10000 - 100 * (1 + abs(50 - target_busy_pct));
> -	unsigned long idle_us = 100 * (busy_us - target_busy_pct *
> -				busy_us / 100) / target_busy_pct;
>   	const unsigned long min_test_us = 1e6;
> -	const unsigned long pwm_calibration_us = min_test_us;
> -	const unsigned long test_us = min_test_us;
> +	unsigned long pwm_calibration_us;
> +	unsigned long test_us;
> +	unsigned long cycle_us, busy_us, idle_us;
>   	double busy_r, expected;
>   	uint64_t val[2];
>   	uint64_t ts[2];
> @@ -1538,18 +1537,27 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e,
>   	/* Sampling platforms cannot reach the high accuracy criteria. */
>   	igt_require(gem_has_execlists(gem_fd));
>   
> -	while (idle_us < 2500) {
> +	/* Aim for approximately 100 iterations for calibration */
> +	cycle_us = min_test_us / target_iters;
> +	busy_us = cycle_us * target_busy_pct / 100;
> +	idle_us = cycle_us - busy_us;

2% load, 1s / 10 iters
	cycles_us = 100ms
	busy_us = 2ms
	idle_us = 98ms
...

> +
> +	while (idle_us < 2500 || busy_us < 2500) {
>   		busy_us *= 2;
>   		idle_us *= 2;

...

busy_us = 4ms
idle_us = 196ms

I fear here that even sampling timers will get it right with this long 
PWM cycle. So we miss to notice GuC mode is inaccurate for real world 
workloads.

Okay question is what are real work workloads.. are they really 
typically shorter than 4ms batches? And what PWM cycle we need here to 
notice this.

I had this empirically worked out to the values that were previously 
used AFAIR, or perhaps there was some leeway. Hmm.. I think finish the 
series with a patch to remove the skip on !has_execlists so CI tells us?

Regards,

Tvrtko

>   	}
> +	cycle_us = busy_us + idle_us;
> +	pwm_calibration_us = target_iters * cycle_us / 2;
> +	test_us = target_iters * cycle_us;
>   
> -	igt_info("calibration=%lums, test=%lums; ratio=%.2f%% (%luus/%luus)\n",
> -		 pwm_calibration_us / 1000, test_us / 1000,
> -		 (double)busy_us / (busy_us + idle_us) * 100.0,
> +	igt_info("calibration=%lums, test=%lums, cycle=%lums; ratio=%.2f%% (%luus/%luus)\n",
> +		 pwm_calibration_us / 1000, test_us / 1000, cycle_us / 1000,
> +		 (double)busy_us / cycle_us * 100.0,
>   		 busy_us, idle_us);
>   
> -	assert_within_epsilon((double)busy_us / (busy_us + idle_us),
> -				(double)target_busy_pct / 100.0, tolerance);
> +	assert_within_epsilon((double)busy_us / cycle_us,
> +			      (double)target_busy_pct / 100.0,
> +			      tolerance);
>   
>   	igt_assert(pipe(link) == 0);
>   
> @@ -1796,7 +1804,7 @@ igt_main
>   			for (i = 0; i < ARRAY_SIZE(pct); i++) {
>   				igt_subtest_f("busy-accuracy-%u-%s",
>   					      pct[i], e->name)
> -					accuracy(fd, e, pct[i]);
> +					accuracy(fd, e, pct[i], 10);
>   			}
>   
>   			igt_subtest_f("busy-hang-%s", e->name)
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: igt-dev@lists.freedesktop.org, Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 1/2] igt/perf_pmu: Aim for a fixed number of iterations for calibrating accuracy
Date: Thu, 9 Aug 2018 12:54:41 +0100	[thread overview]
Message-ID: <8257df1e-bf5d-7ba2-c423-12b98da696c2@linux.intel.com> (raw)
In-Reply-To: <20180808145945.26159-1-chris@chris-wilson.co.uk>


On 08/08/2018 15:59, Chris Wilson wrote:
> Our observation is that the systematic error is proportional to the
> number of iterations we perform; the suspicion is that it directly
> correlates with the number of sleeps. Reduce the number of iterations,
> to try and keep the error in check.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   tests/perf_pmu.c | 34 +++++++++++++++++++++-------------
>   1 file changed, 21 insertions(+), 13 deletions(-)
> 
> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> index 9a20abb6b..5a26d5272 100644
> --- a/tests/perf_pmu.c
> +++ b/tests/perf_pmu.c
> @@ -1521,14 +1521,13 @@ static void __rearm_spin_batch(igt_spin_t *spin)
>   
>   static void
>   accuracy(int gem_fd, const struct intel_execution_engine2 *e,
> -	 unsigned long target_busy_pct)
> +	 unsigned long target_busy_pct,
> +	 unsigned long target_iters)
>   {
> -	unsigned long busy_us = 10000 - 100 * (1 + abs(50 - target_busy_pct));
> -	unsigned long idle_us = 100 * (busy_us - target_busy_pct *
> -				busy_us / 100) / target_busy_pct;
>   	const unsigned long min_test_us = 1e6;
> -	const unsigned long pwm_calibration_us = min_test_us;
> -	const unsigned long test_us = min_test_us;
> +	unsigned long pwm_calibration_us;
> +	unsigned long test_us;
> +	unsigned long cycle_us, busy_us, idle_us;
>   	double busy_r, expected;
>   	uint64_t val[2];
>   	uint64_t ts[2];
> @@ -1538,18 +1537,27 @@ accuracy(int gem_fd, const struct intel_execution_engine2 *e,
>   	/* Sampling platforms cannot reach the high accuracy criteria. */
>   	igt_require(gem_has_execlists(gem_fd));
>   
> -	while (idle_us < 2500) {
> +	/* Aim for approximately 100 iterations for calibration */
> +	cycle_us = min_test_us / target_iters;
> +	busy_us = cycle_us * target_busy_pct / 100;
> +	idle_us = cycle_us - busy_us;

2% load, 1s / 10 iters
	cycles_us = 100ms
	busy_us = 2ms
	idle_us = 98ms
...

> +
> +	while (idle_us < 2500 || busy_us < 2500) {
>   		busy_us *= 2;
>   		idle_us *= 2;

...

busy_us = 4ms
idle_us = 196ms

I fear here that even sampling timers will get it right with this long 
PWM cycle. So we miss to notice GuC mode is inaccurate for real world 
workloads.

Okay question is what are real work workloads.. are they really 
typically shorter than 4ms batches? And what PWM cycle we need here to 
notice this.

I had this empirically worked out to the values that were previously 
used AFAIR, or perhaps there was some leeway. Hmm.. I think finish the 
series with a patch to remove the skip on !has_execlists so CI tells us?

Regards,

Tvrtko

>   	}
> +	cycle_us = busy_us + idle_us;
> +	pwm_calibration_us = target_iters * cycle_us / 2;
> +	test_us = target_iters * cycle_us;
>   
> -	igt_info("calibration=%lums, test=%lums; ratio=%.2f%% (%luus/%luus)\n",
> -		 pwm_calibration_us / 1000, test_us / 1000,
> -		 (double)busy_us / (busy_us + idle_us) * 100.0,
> +	igt_info("calibration=%lums, test=%lums, cycle=%lums; ratio=%.2f%% (%luus/%luus)\n",
> +		 pwm_calibration_us / 1000, test_us / 1000, cycle_us / 1000,
> +		 (double)busy_us / cycle_us * 100.0,
>   		 busy_us, idle_us);
>   
> -	assert_within_epsilon((double)busy_us / (busy_us + idle_us),
> -				(double)target_busy_pct / 100.0, tolerance);
> +	assert_within_epsilon((double)busy_us / cycle_us,
> +			      (double)target_busy_pct / 100.0,
> +			      tolerance);
>   
>   	igt_assert(pipe(link) == 0);
>   
> @@ -1796,7 +1804,7 @@ igt_main
>   			for (i = 0; i < ARRAY_SIZE(pct); i++) {
>   				igt_subtest_f("busy-accuracy-%u-%s",
>   					      pct[i], e->name)
> -					accuracy(fd, e, pct[i]);
> +					accuracy(fd, e, pct[i], 10);
>   			}
>   
>   			igt_subtest_f("busy-hang-%s", e->name)
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  parent reply	other threads:[~2018-08-09 11:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-08 14:59 [PATCH i-g-t 1/2] igt/perf_pmu: Aim for a fixed number of iterations for calibrating accuracy Chris Wilson
2018-08-08 14:59 ` [igt-dev] " Chris Wilson
2018-08-08 14:59 ` [PATCH i-g-t 2/2] igt/perf_pmu: Improve the presentation of the accuracy calibration Chris Wilson
2018-08-08 14:59   ` [Intel-gfx] " Chris Wilson
2018-08-30 16:53   ` Tvrtko Ursulin
2018-08-30 16:53     ` [Intel-gfx] " Tvrtko Ursulin
2018-08-08 15:38 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/2] igt/perf_pmu: Aim for a fixed number of iterations for calibrating accuracy Patchwork
2018-08-08 21:49 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2018-08-09 11:54 ` Tvrtko Ursulin [this message]
2018-08-09 11:54   ` [igt-dev] [PATCH i-g-t 1/2] " Tvrtko Ursulin
2018-08-10 13:25   ` Chris Wilson
2018-08-10 13:25     ` Chris Wilson
2018-08-13  9:20     ` Tvrtko Ursulin
2018-08-13  9:20       ` Tvrtko Ursulin
2018-08-30 16:31 ` Tvrtko Ursulin
2018-08-30 16:31   ` [igt-dev] [Intel-gfx] " Tvrtko Ursulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8257df1e-bf5d-7ba2-c423-12b98da696c2@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.