From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org
Subject: [PATCH v5 4/5] drm/i915: Do not lie about atomic timeout granularity
Date: Thu, 3 Mar 2016 16:21:27 +0000 [thread overview]
Message-ID: <1457022087-18250-1-git-send-email-tvrtko.ursulin@linux.intel.com> (raw)
In-Reply-To: <20160303161005.GU30782@nuc-i3427.alporthouse.com>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Currently the wait_for_atomic_us only allows for a jiffie
timeout granularity which is not nice towards callers
requesting small micro-second timeouts.
Re-implement it so micro-second timeout granularity is really
supported and not just in the name of the macro.
This has another beneficial side effect that it improves
"gem_latency -n 100" results by approximately 2.5% (throughput
and latencies) and 3% (CPU usage). (Note this improvement is
relative to not yet merged execlist lock uncontention patch
which moves the CSB MMIO outside this lock.)
It also shrinks some hot functions like fw_domains_get by a
tiny 3%.
v2:
* Warn when used from non-atomic context (if possible).
* Warn on too long atomic waits.
v3:
* Added comment explaining CONFIG_PREEMPT_COUNT.
* Fixed pre-processor indentation.
(Chris Wilson)
v4:
* Commit msg update (gem_latency) and rebase.
v5:
* Commit message re-wording.
* Added comment about no need for double cond check. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_drv.h | 37 +++++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2a62e9554b3..7819ddb51745 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -44,6 +44,10 @@
* contexts. Note that it's important that we check the condition again after
* having timed out, since the timeout could be due to preemption or similar and
* we've never had a chance to check the condition before the timeout.
+ *
+ * TODO: When modesetting has fully transitioned to atomic, the below
+ * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
+ * added.
*/
#define _wait_for(COND, US, W) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1; \
@@ -66,8 +70,37 @@
#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 1000)
#define wait_for_us(COND, US) _wait_for((COND), (US), 1)
-#define wait_for_atomic(COND, MS) _wait_for((COND), (MS) * 1000, 0)
-#define wait_for_atomic_us(COND, US) _wait_for((COND), (US), 0)
+/* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
+#if defined(CONFIG_DRM_I915_DEBUG) && defined(CONFIG_PREEMPT_COUNT)
+# define _WAIT_FOR_ATOMIC_CHECK WARN_ON_ONCE(!in_atomic())
+#else
+# define _WAIT_FOR_ATOMIC_CHECK do { } while(0)
+#endif
+
+#define _wait_for_atomic(COND, US) ({ \
+ unsigned long end__; \
+ int ret__ = 0; \
+ _WAIT_FOR_ATOMIC_CHECK; \
+ BUILD_BUG_ON((US) > 50000); \
+ end__ = (local_clock() >> 10) + (US) + 1; \
+ while (!(COND)) { \
+ if (time_after((unsigned long)(local_clock() >> 10), end__)) { \
+ /* Unlike the regular wait_for(), this atomic variant \
+ * cannot be preempted (and we'll just ignore the issue\
+ * of irq interruptions) and so we know that no time \
+ * has passed since the last check of COND and can \
+ * immediately report the timeout. \
+ */ \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ cpu_relax(); \
+ } \
+ ret__; \
+})
+
+#define wait_for_atomic(COND, MS) _wait_for_atomic((COND), (MS) * 1000)
+#define wait_for_atomic_us(COND, US) _wait_for_atomic((COND), (US))
#define KHz(x) (1000 * (x))
#define MHz(x) KHz(1000 * (x))
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-03 16:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 14:36 [PATCH 1/5] drm/i915: Add wait_for_us Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 2/5] drm/i915/lrc: Do not wait atomically when stopping engines Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 3/5] drm/i915: Kconfig for extra driver debugging Tvrtko Ursulin
2016-03-03 14:36 ` [PATCH 4/5] drm/i915: Do not lie about atomic wait granularity Tvrtko Ursulin
2016-03-03 15:11 ` Chris Wilson
2016-03-03 15:43 ` Tvrtko Ursulin
2016-03-03 16:10 ` Chris Wilson
2016-03-03 16:21 ` Tvrtko Ursulin [this message]
2016-03-03 14:36 ` [PATCH 5/5] drm/i915: Do not wait atomically for display clocks Tvrtko Ursulin
2016-03-03 15:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Add wait_for_us Patchwork
2016-03-03 17:01 ` Tvrtko Ursulin
2016-03-03 17:20 ` Chris Wilson
2016-03-03 17:35 ` Tvrtko Ursulin
2016-03-03 17:01 ` ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Add wait_for_us (rev2) 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=1457022087-18250-1-git-send-email-tvrtko.ursulin@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox