All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: 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 18:04:42 +0300	[thread overview]
Message-ID: <aG_VzpXaYRCQQGYt@intel.com> (raw)
In-Reply-To: <20250710064136.rur6FoOU@linutronix.de>

On Thu, Jul 10, 2025 at 08:41:36AM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-07-09 23:09:22 [+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.
> 
> Well it works on my machine and this machine dose not pass the code
> paths that I patch.
> 
> Every patch made was done because someone reported an error/ warning and
> confirmed afterwards that the patch fixes it for them and they can use
> the machine and don't observe anything.
> 
> > 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.
> 
> no, not just that. Making the lock raw led to latency spikes in simple
> spikes and I just disabled trace points. It could be worked around by
> taking the lock if the tracepoint is enabled and then invoking the
> tracepoint unconditionally and not taking the lock anymore. Steven made
> a suggestion a while ago how to put this in macro as far as I remember.

When this was last discussed I suggested that there should be a
versions of the tracepoint macros that do the sampling outside
the lock, but that wasn't deemed acceptable for whatever reason.
I don't even know why the current macros are doing the
sampling while holding the lock...

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-07-10 15:04 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
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ä [this message]
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=aG_VzpXaYRCQQGYt@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=ben@decadent.org.uk \
    --cc=bigeasy@linutronix.de \
    --cc=debian-kernel@lists.debian.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-rt-users@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.