Hi Sebastian, first of all, thanks for your answer and for the help! On Thu, 6 Dec 2018 at 10:10, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: [...] > > 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. I tried to enable ftrace to debug the latency issues, but I probably screwed up and enabled too many things... :) BTW, I tried to search for some document explaining what to enable and what to disable in .config in order to get a well-performing RT kernel, but I did not find anything useful... Does anyone have recommendations about documents to read for correctly configuring a PREEMPT_RT kernel? > 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. Thanks for the patch! I am going to try it immediately. BTW, playing with some options I discovered that if I add "nohz=off" to the kernel commandline I get a maximum latency of about 150us when using the i915 driver, and less than 100us when not using it. I am going to test your patch, and to disable debugging and tracing... I'll let you know the results. Thanks again, Luca > 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 >
