public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Matthew Brost <matthew.brost@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Ben Hutchings" <ben@decadent.org.uk>,
	linux-rt-users@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	"Debian kernel maintainers" <debian-kernel@lists.debian.org>
Subject: Re: PREEMPT_RT vs i915
Date: Thu, 10 Jul 2025 08:30:14 +0200	[thread overview]
Message-ID: <20250710063014.eOrcpX6Y@linutronix.de> (raw)
In-Reply-To: <aG7na/6m/IcrJ3xx@lstrano-desk.jf.intel.com>

On 2025-07-09 15:04:27 [-0700], Matthew Brost wrote:
> > And IIRC the other remaining problem with RT was the spinlocks used
> > inside tracepoints (which is uncore lock, and probably some vblank
> > locks). So that too needs some kind of solution because it's going to
> > very hard to debug the timing sensitive parts without the tracepoints.
> 
> A bit of a drive-by comment, but taking locks inside tracepoints seems
> like a pretty horrible idea in general. We've managed to write an entire
> driver (Xe) from scratch and bring it up without doing this. I'd be very
> surprised if this is truly necessary in i915.

Steven made suggestions how to get around it make it work but my
impression was that this was not appreciated by the i915 side.
The general unwritten rule is to not to take any locks but simply assign
variables.

> Matt

Sebastian

  reply	other threads:[~2025-07-10  6:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08 19:35 PREEMPT_RT vs i915 Ben Hutchings
2025-07-09 17:30 ` Ville Syrjälä
2025-07-09 19:44   ` Sebastian Andrzej Siewior
2025-07-09 20:09     ` Ville Syrjälä
2025-07-09 22:04       ` Matthew Brost
2025-07-10  6:30         ` Sebastian Andrzej Siewior [this message]
2025-07-10 15:21         ` Ville Syrjälä
2025-07-10 18:04           ` Matthew Brost
2025-07-10 18:15             ` Ville Syrjälä
2025-07-10  4:52       ` Mike Galbraith
2025-07-10 15:50         ` Ville Syrjälä
2025-07-11  2:36           ` Mike Galbraith
2025-07-11  3:33             ` Mike Galbraith
2025-07-11  8:05               ` block: lockdep splat with RT config v6.15+ Mike Galbraith
2025-07-11  8:59                 ` Sebastian Andrzej Siewior
2025-07-11  9:03                   ` Mike Galbraith
2025-07-10  6:41       ` PREEMPT_RT vs i915 Sebastian Andrzej Siewior
2025-07-10 15:04         ` Ville Syrjälä
2025-07-10 15:20           ` Sebastian Andrzej Siewior
2025-07-11 12:35             ` Maarten Lankhorst

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=20250710063014.eOrcpX6Y@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=ben@decadent.org.uk \
    --cc=debian-kernel@lists.debian.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /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