forked from Minki/linux
9512f985c3
Back in commit27af5eea54
("drm/i915: Move execlists irq handler to a bottom half"), we came to the conclusion that running our CSB processing and ELSP submission from inside the irq handler was a bad idea. A really bad idea as we could impose nearly 1s latency on other users of the system, on average! Deferring our work to a tasklet allowed us to do the processing with irqs enabled, reducing the impact to an average of about 50us. We have since eradicated the use of forcewaked mmio from inside the CSB processing and ELSP submission, bringing the impact down to around 5us (on Kabylake); an order of magnitude better than our measurements 2 years ago on Broadwell and only about 2x worse on average than the gem_syslatency on an unladen system. In this iteration of the tasklet-vs-direct submission debate, we seek a compromise where by we submit new requests immediately to the HW but defer processing the CS interrupt onto a tasklet. We gain the advantage of low-latency and ksoftirqd avoidance when waking up the HW, while avoiding the system-wide starvation of our CS irq-storms. Comparing the impact on the maximum latency observed (that is the time stolen from an RT process) over a 120s interval, repeated several times (using gem_syslatency, similar to RT's cyclictest) while the system is fully laden with i915 nops, we see that direct submission an actually improve the worse case. Maximum latency in microseconds of a third party RT thread (gem_syslatency -t 120 -f 2) x Always using tasklets (a couple of >1000us outliers removed) + Only using tasklets from CS irq, direct submission of requests +------------------------------------------------------------------------+ | + | | + | | + | | + + | | + + + | | + + + + x x x | | +++ + + + x x x x x x | | +++ + ++ + + *x x x x x x | | +++ + ++ + * *x x * x x x | | + +++ + ++ * * +*xxx * x x xx | | * +++ + ++++* *x+**xx+ * x x xxxx x | | **x++++*++**+*x*x****x+ * +x xx xxxx x x | |x* ******+***************++*+***xxxxxx* xx*x xxx + x+| | |__________MA___________| | | |______M__A________| | +------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 118 91 186 124 125.28814 16.279137 + 120 92 187 109 112.00833 13.458617 Difference at 95.0% confidence -13.2798 +/- 3.79219 -10.5994% +/- 3.02677% (Student's t, pooled s = 14.9237) However the mean latency is adversely affected: Mean latency in microseconds of a third party RT thread (gem_syslatency -t 120 -f 1) x Always using tasklets + Only using tasklets from CS irq, direct submission of requests +------------------------------------------------------------------------+ | xxxxxx + ++ | | xxxxxx + ++ | | xxxxxx + +++ ++ | | xxxxxxx +++++ ++ | | xxxxxxx +++++ ++ | | xxxxxxx +++++ +++ | | xxxxxxx + ++++++++++ | | xxxxxxxx ++ ++++++++++ | | xxxxxxxx ++ ++++++++++ | | xxxxxxxxxx +++++++++++++++ | | xxxxxxxxxxx x +++++++++++++++ | |x xxxxxxxxxxxxx x + + ++++++++++++++++++ +| | |__A__| | | |____A___| | +------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 3.506 3.727 3.631 3.6321417 0.02773109 + 120 3.834 4.149 4.039 4.0375167 0.041221676 Difference at 95.0% confidence 0.405375 +/- 0.00888913 11.1608% +/- 0.244735% (Student's t, pooled s = 0.03513) However, since the mean latency corresponds to the amount of irqsoff processing we have to do for a CS interrupt, we only need to speed that up to benefit not just system latency but our own throughput. v2: Remember to defer submissions when under reset. v4: Only use direct submission for new requests v5: Be aware that with mixing direct tasklet evaluation and deferred tasklets, we may end up idling before running the deferred tasklet. v6: Remove the redudant likely() from tasklet_is_enabled(), restrict the annotation to reset_in_progress(). v7: Take the full timeline.lock when enabling perf_pmu stats as the tasklet is no longer a valid guard. A consequence is that the stats are now only valid for engines also using the timeline.lock to process state. Testcase: igt/gem_exec_latency/*rthog* References:27af5eea54
("drm/i915: Move execlists irq handler to a bottom half") Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-9-chris@chris-wilson.co.uk
97 lines
2.9 KiB
C
97 lines
2.9 KiB
C
/*
|
|
* Copyright © 2016 Intel Corporation
|
|
*
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
* to deal in the Software without restriction, including without limitation
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
*
|
|
* The above copyright notice and this permission notice (including the next
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
* Software.
|
|
*
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
* IN THE SOFTWARE.
|
|
*
|
|
*/
|
|
|
|
#ifndef __I915_GEM_H__
|
|
#define __I915_GEM_H__
|
|
|
|
#include <linux/bug.h>
|
|
#include <linux/interrupt.h>
|
|
|
|
struct drm_i915_private;
|
|
|
|
#ifdef CONFIG_DRM_I915_DEBUG_GEM
|
|
|
|
#define GEM_SHOW_DEBUG() (drm_debug & DRM_UT_DRIVER)
|
|
|
|
#define GEM_BUG_ON(condition) do { if (unlikely((condition))) { \
|
|
pr_err("%s:%d GEM_BUG_ON(%s)\n", \
|
|
__func__, __LINE__, __stringify(condition)); \
|
|
GEM_TRACE("%s:%d GEM_BUG_ON(%s)\n", \
|
|
__func__, __LINE__, __stringify(condition)); \
|
|
BUG(); \
|
|
} \
|
|
} while(0)
|
|
#define GEM_WARN_ON(expr) WARN_ON(expr)
|
|
|
|
#define GEM_DEBUG_DECL(var) var
|
|
#define GEM_DEBUG_EXEC(expr) expr
|
|
#define GEM_DEBUG_BUG_ON(expr) GEM_BUG_ON(expr)
|
|
|
|
#else
|
|
|
|
#define GEM_SHOW_DEBUG() (0)
|
|
|
|
#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
|
|
#define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
|
|
|
|
#define GEM_DEBUG_DECL(var)
|
|
#define GEM_DEBUG_EXEC(expr) do { } while (0)
|
|
#define GEM_DEBUG_BUG_ON(expr)
|
|
#endif
|
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_TRACE_GEM)
|
|
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
|
|
#define GEM_TRACE_DUMP() ftrace_dump(DUMP_ALL)
|
|
#define GEM_TRACE_DUMP_ON(expr) \
|
|
do { if (expr) ftrace_dump(DUMP_ALL); } while (0)
|
|
#else
|
|
#define GEM_TRACE(...) do { } while (0)
|
|
#define GEM_TRACE_DUMP() do { } while (0)
|
|
#define GEM_TRACE_DUMP_ON(expr) BUILD_BUG_ON_INVALID(expr)
|
|
#endif
|
|
|
|
#define I915_NUM_ENGINES 8
|
|
|
|
void i915_gem_park(struct drm_i915_private *i915);
|
|
void i915_gem_unpark(struct drm_i915_private *i915);
|
|
|
|
static inline void __tasklet_disable_sync_once(struct tasklet_struct *t)
|
|
{
|
|
if (atomic_inc_return(&t->count) == 1)
|
|
tasklet_unlock_wait(t);
|
|
}
|
|
|
|
static inline void __tasklet_enable_sync_once(struct tasklet_struct *t)
|
|
{
|
|
if (atomic_dec_return(&t->count) == 0)
|
|
tasklet_kill(t);
|
|
}
|
|
|
|
static inline bool __tasklet_is_enabled(const struct tasklet_struct *t)
|
|
{
|
|
return !atomic_read(&t->count);
|
|
}
|
|
|
|
#endif /* __I915_GEM_H__ */
|