Re: PREEMPT_RT vs i915

Ville Syrjälä
2025-07-10T15:50:18Z

On Thu, Jul 10, 2025 at 06:52:58AM +0200, Mike Galbraith wrote:
> On Wed, 2025-07-09 at 23:09 +0300, Ville Syrjälä wrote:
> > On Wed, Jul 09, 2025 at 09:44:43PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2025-07-09 20:30:26 [+0300], Ville Syrjälä wrote:
> > > > >
> > > > > It seems like the critical uncore lock is currently held in a lot of
> > > > > places and potentially for a long time.
> > > >
> > > > It shouldn't be held for that long. I think it should just be
> > > > a raw spinlock.
> > >
> > > What about I resubmit the series and we look again? I don't think the
> > > lock should be made raw just to be done with it.
> >
> > Until someone actually does the work to confirm the thing is working
> > reliably there's no point in posting anything.
>
> What does that entail?

Basic testing would be something like this:
- enable CONFIG_DRM_I915_DEBUG_VBLANK_EVADE
- set i915.enable_dsb=0 to make sure everything takes the
mmio path
- stress the heck out of it and make sure the histogram
doesn't look significantly worse than on !RT
(kms_atomic_transition --extended might take care of the display
side here, but it should probably be accompanied with some
horrendous system loads which is a less well defined part)
- ideally do that on a potato
(some VLV/CHV (Atom) thing would probably be a good candidate)
- repeat with lockdep enabled to make everything even harder

--
Ville Syrjälä
Intel