Re: PREEMPT_RT and i915

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2018-11-30 13:29:28 [+0100], Luca Abeni wrote:
> Hi all,
Hi,

> I am running some experiments on my laptop, based on an Intel i5 CPU
> ("Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz", according to
> /proc/cpuinfo), and cyclictest shows high latencies with both
> 4.14.78-rt47 and 4.19.1-rt3 (of course, I enabled PREEMPT_RT_FULL).
…
> While running some of these experiments with cyclictest, I found the
> attached BUG() in dmesg... Since it seems to indicate a problem in the
> i915 driver (looks like there is a spinlock - "uncore.lock"? - that is
> locked when preemption is disabled, or something similar... Should it
> be a raw spinlock?), I recompiled the kernel with the i915 driver
> disabled.

You seem to have debugging / tracing enabled. This might cause extra
latencies. For the backtrace you provided I disabled the i915
tracepoints. They invoke functions within their trace points which
acquire spin locks and this does not work on RT.
Steven, don't have a document somewhere saying "don't do this"? I
remember you patched it out from cgroups.

> So, I am wondering if there is some known issue with the i915 driver
> and real-time... In case this is not a known issue, I can run
> additional tests and provide more data if needed.

The patch for the i915 thingy is attached below. Now you shouldn't see
the splat anymore. For lowest latency testing you shouldn't enabling
trace points and/or other debugging.

> Thanks,
> Luca

---->8----

Subject: [PATCH] drm/i915: disable tracing on -RT

Luca Abeni reported this:
| BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003
| CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
| Call Trace:
|  rt_spin_lock+0x3f/0x50
|  gen6_read32+0x45/0x1d0 [i915]
|  g4x_get_vblank_counter+0x36/0x40 [i915]
|  trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915]

The tracing events use trace_i915_pipe_update_start() among other events
use functions acquire spin locks. A few trace points use
intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also
might acquire a sleeping lock.

Based on this I don't see any other way than disable trace points on RT.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
---
 drivers/gpu/drm/i915/i915_trace.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index b50c6b829715e..cc54ec0ef75c1 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -2,6 +2,10 @@
 #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
 #define _I915_TRACE_H_
 
+#ifdef CONFIG_PREEMPT_RT_BASE
+#define NOTRACE
+#endif
+
 #include <linux/stringify.h>
 #include <linux/types.h>
 #include <linux/tracepoint.h>
-- 
2.20.0.rc2




[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux