From: Matthew Brost <matthew.brost@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/pmu: Increase the live_engine_busy_stats sample period
Date: Fri, 12 Nov 2021 12:51:51 -0800 [thread overview]
Message-ID: <20211112205151.GA9801@jons-linux-dev-box> (raw)
In-Reply-To: <20211112025222.61031-1-umesh.nerlige.ramappa@intel.com>
On Thu, Nov 11, 2021 at 06:52:22PM -0800, Umesh Nerlige Ramappa wrote:
> Irrespective of the backend for request submissions, busyness for an
> engine with an active context is calculated using:
>
> busyness = total + (current_time - context_switch_in_time)
>
> In execlists mode of operation, the context switch events are handled
> by the CPU. Context switch in/out time and current_time are captured
> in CPU time domain using ktime_get().
>
> In GuC mode of submission, context switch events are handled by GuC and
> the times in the above formula are captured in GT clock domain. This
> information is shared with the CPU through shared memory. This results
> in 2 caveats:
>
> 1) The time taken between start of a batch and the time that CPU is able
> to see the context_switch_in_time in shared memory is dependent on GuC
> and memory bandwidth constraints.
>
> 2) Determining current_time requires an MMIO read that can take anywhere
> between a few us to a couple ms. A reference CPU time is captured soon
> after reading the MMIO so that the caller can compare the cpu delta
> between 2 busyness samples. The issue here is that the CPU delta and the
> busyness delta can be skewed because of the time taken to read the
> register.
>
> These 2 factors affect the accuracy of the selftest -
> live_engine_busy_stats. For (1) the selftest waits until busyness stats
> are visible to the CPU. The effects of (2) are more prominent for the
> current busyness sample period of 100 us. Increase the busyness sample
> period from 100 us to 10 ms to overccome (2).
>
> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Explaination of increased wait period makes sense to me.
With that:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> index 0bfd738dbf3a..96cc565afa78 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> @@ -316,7 +316,7 @@ static int live_engine_busy_stats(void *arg)
> ENGINE_TRACE(engine, "measuring busy time\n");
> preempt_disable();
> de = intel_engine_get_busy_time(engine, &t[0]);
> - udelay(100);
> + udelay(10000);
> de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
> preempt_enable();
> dt = ktime_sub(t[1], t[0]);
> --
> 2.20.1
>
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
intel-gfx@lists.freedesktop.org, john.c.harrison@intel.com,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/pmu: Increase the live_engine_busy_stats sample period
Date: Fri, 12 Nov 2021 12:51:51 -0800 [thread overview]
Message-ID: <20211112205151.GA9801@jons-linux-dev-box> (raw)
In-Reply-To: <20211112025222.61031-1-umesh.nerlige.ramappa@intel.com>
On Thu, Nov 11, 2021 at 06:52:22PM -0800, Umesh Nerlige Ramappa wrote:
> Irrespective of the backend for request submissions, busyness for an
> engine with an active context is calculated using:
>
> busyness = total + (current_time - context_switch_in_time)
>
> In execlists mode of operation, the context switch events are handled
> by the CPU. Context switch in/out time and current_time are captured
> in CPU time domain using ktime_get().
>
> In GuC mode of submission, context switch events are handled by GuC and
> the times in the above formula are captured in GT clock domain. This
> information is shared with the CPU through shared memory. This results
> in 2 caveats:
>
> 1) The time taken between start of a batch and the time that CPU is able
> to see the context_switch_in_time in shared memory is dependent on GuC
> and memory bandwidth constraints.
>
> 2) Determining current_time requires an MMIO read that can take anywhere
> between a few us to a couple ms. A reference CPU time is captured soon
> after reading the MMIO so that the caller can compare the cpu delta
> between 2 busyness samples. The issue here is that the CPU delta and the
> busyness delta can be skewed because of the time taken to read the
> register.
>
> These 2 factors affect the accuracy of the selftest -
> live_engine_busy_stats. For (1) the selftest waits until busyness stats
> are visible to the CPU. The effects of (2) are more prominent for the
> current busyness sample period of 100 us. Increase the busyness sample
> period from 100 us to 10 ms to overccome (2).
>
> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Explaination of increased wait period makes sense to me.
With that:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> index 0bfd738dbf3a..96cc565afa78 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c
> @@ -316,7 +316,7 @@ static int live_engine_busy_stats(void *arg)
> ENGINE_TRACE(engine, "measuring busy time\n");
> preempt_disable();
> de = intel_engine_get_busy_time(engine, &t[0]);
> - udelay(100);
> + udelay(10000);
> de = ktime_sub(intel_engine_get_busy_time(engine, &t[1]), de);
> preempt_enable();
> dt = ktime_sub(t[1], t[0]);
> --
> 2.20.1
>
next prev parent reply other threads:[~2021-11-12 20:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-12 2:52 [Intel-gfx] [PATCH] drm/i915/pmu: Increase the live_engine_busy_stats sample period Umesh Nerlige Ramappa
2021-11-12 2:52 ` Umesh Nerlige Ramappa
2021-11-12 3:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-11-12 3:14 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-11-12 3:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-11-12 11:55 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-11-12 20:51 ` Matthew Brost [this message]
2021-11-12 20:51 ` [PATCH] " Matthew Brost
-- strict thread matches above, loose matches on Subject: below --
2021-11-15 22:16 [Intel-gfx] " Umesh Nerlige Ramappa
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=20211112205151.GA9801@jons-linux-dev-box \
--to=matthew.brost@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=umesh.nerlige.ramappa@intel.com \
/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.