From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: imre.deak@intel.com
Cc: David Airlie <airlied@linux.ie>,
Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2] drm/i915/pmu: Fix sleep under atomic in RC6 readout
Date: Wed, 7 Feb 2018 15:06:46 +0100 [thread overview]
Message-ID: <6a7d6ffc-ae2d-e335-8ffe-2682f76eb5d2@intel.com> (raw)
In-Reply-To: <20180206215447.mo6f772gcqzj6ivt@ideak-desk.fi.intel.com>
On 2/6/2018 10:54 PM, Imre Deak wrote:
> Hi Rafael,
>
> On Tue, Feb 06, 2018 at 09:11:02PM +0000, Chris Wilson wrote:
>> Quoting Tvrtko Ursulin (2018-02-06 18:33:11)
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> We are not allowed to call intel_runtime_pm_get from the PMU counter read
>>> callback since the former can sleep, and the latter is running under IRQ
>>> context.
>>>
>>> To workaround this, we record the last known RC6 and while runtime
>>> suspended estimate its increase by querying the runtime PM core
>>> timestamps.
>>>
>>> Downside of this approach is that we can temporarily lose a chunk of RC6
>>> time, from the last PMU read-out to runtime suspend entry, but that will
>>> eventually catch up, once device comes back online and in the presence of
>>> PMU queries.
>>>
>>> Also, we have to be careful not to overshoot the RC6 estimate, so once
>>> resumed after a period of approximation, we only update the counter once
>>> it catches up. With the observation that RC6 is increasing while the
>>> device is suspended, this should not pose a problem and can only cause
>>> slight inaccuracies due clock base differences.
>>>
>>> v2: Simplify by estimating on top of PM core counters. (Imre)
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104943
>>> Fixes: 6060b6aec03c ("drm/i915/pmu: Add RC6 residency metrics")
>>> Testcase: igt/perf_pmu/rc6-runtime-pm
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Imre Deak <imre.deak@intel.com>
>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
>>> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> Cc: David Airlie <airlied@linux.ie>
>>> Cc: intel-gfx@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> ---
>>> drivers/gpu/drm/i915/i915_pmu.c | 93 ++++++++++++++++++++++++++++++++++-------
>>> drivers/gpu/drm/i915/i915_pmu.h | 6 +++
>>> 2 files changed, 84 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
>>> index 1c440460255d..bfc402d47609 100644
>>> --- a/drivers/gpu/drm/i915/i915_pmu.c
>>> +++ b/drivers/gpu/drm/i915/i915_pmu.c
>>> @@ -415,7 +415,81 @@ static int i915_pmu_event_init(struct perf_event *event)
>>> return 0;
>>> }
>>>
>>> -static u64 __i915_pmu_event_read(struct perf_event *event)
>>> +static u64 get_rc6(struct drm_i915_private *i915, bool locked)
>>> +{
>>> + unsigned long flags;
>>> + u64 val;
>>> +
>>> + if (intel_runtime_pm_get_if_in_use(i915)) {
>>> + val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
>>> + VLV_GT_RENDER_RC6 :
>>> + GEN6_GT_GFX_RC6);
>>> +
>>> + if (HAS_RC6p(i915))
>>> + val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
>>> +
>>> + if (HAS_RC6pp(i915))
>>> + val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
>>> +
>>> + intel_runtime_pm_put(i915);
>>> +
>>> + /*
>>> + * If we are coming back from being runtime suspended we must
>>> + * be careful not to report a larger value than returned
>>> + * previously.
>>> + */
>>> +
>>> + if (!locked)
>>> + spin_lock_irqsave(&i915->pmu.lock, flags);
>>> +
>>> + if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
>>> + i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
>>> + i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
>>> + } else {
>>> + val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
>>> + }
>>> +
>>> + if (!locked)
>>> + spin_unlock_irqrestore(&i915->pmu.lock, flags);
>>> + } else {
>>> + struct pci_dev *pdev = i915->drm.pdev;
>>> + struct device *kdev = &pdev->dev;
>>> + unsigned long flags2;
>>> +
>>> + /*
>>> + * We are runtime suspended.
>>> + *
>>> + * Report the delta from when the device was suspended to now,
>>> + * on top of the last known real value, as the approximated RC6
>>> + * counter value.
>>> + */
>>> + if (!locked)
>>> + spin_lock_irqsave(&i915->pmu.lock, flags);
>>> +
>>> + spin_lock_irqsave(&kdev->power.lock, flags2);
>>> +
>>> + if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
>>> + i915->pmu.suspended_jiffies_last =
>>> + kdev->power.suspended_jiffies;
>>> +
>>> + val = kdev->power.suspended_jiffies -
>>> + i915->pmu.suspended_jiffies_last;
>>> + val += jiffies - kdev->power.accounting_timestamp;
>>> +
>>> + spin_unlock_irqrestore(&kdev->power.lock, flags2);
>>> +
>>> + val = jiffies_to_nsecs(val);
>>> + val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
>>> + i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
>>> +
>>> + if (!locked)
>>> + spin_unlock_irqrestore(&i915->pmu.lock, flags);
>>> + }
>>> +
>>> + return val;
>>> +}
>> I feel slightly dirty, but the dance checks out.
> Would it be possible to add an RPM helper that provides the device's
> runtime suspend residency for the above purpose? This would be
> essentially what rtpm_suspended_time_show() provides.
Yes, in general, but as already mentioned in this thread, I guess it's
better to do that later as an extra step for the backportability sake.
Thanks,
Rafael
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-02-07 14:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-06 14:31 [PATCH] drm/i915/pmu: Fix sleep under atomic in RC6 readout Tvrtko Ursulin
2018-02-06 15:13 ` ✗ Fi.CI.BAT: warning for " Patchwork
2018-02-06 16:04 ` [PATCH] " Chris Wilson
2018-02-06 16:10 ` Imre Deak
2018-02-06 17:12 ` [Intel-gfx] " Tvrtko Ursulin
2018-02-06 18:33 ` [PATCH v2] " Tvrtko Ursulin
2018-02-06 21:11 ` Chris Wilson
2018-02-06 21:54 ` Imre Deak
2018-02-07 9:20 ` [Intel-gfx] " Tvrtko Ursulin
2018-02-07 9:36 ` Chris Wilson
2018-02-07 14:06 ` Rafael J. Wysocki [this message]
2018-02-06 19:16 ` ✓ Fi.CI.BAT: success for drm/i915/pmu: Fix sleep under atomic in RC6 readout (rev2) Patchwork
2018-02-07 9:40 ` Patchwork
2018-02-07 13:40 ` Tvrtko Ursulin
2018-02-07 12:10 ` ✗ Fi.CI.IGT: failure " Patchwork
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=6a7d6ffc-ae2d-e335-8ffe-2682f76eb5d2@intel.com \
--to=rafael.j.wysocki@intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=imre.deak@intel.com \
--cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox