From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
linux-rt-users@vger.kernel.org, intel-gfx@lists.freedesktop.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] tentative fix for drm/i915/gt regression on preempt-rt
Date: Fri, 30 Jun 2023 15:09:49 +0200 [thread overview]
Message-ID: <20230630130949.coN0sVU4@linutronix.de> (raw)
In-Reply-To: <ZJTuDi1HNp9L2zxY@windriver.com>
On 2023-06-22 20:57:50 [-0400], Paul Gortmaker wrote:
[ longer report about what is broken.]
Commit ade8a0f598443 ("drm/i915: Make all GPU resets atomic") introduces
a preempt_disable() section around the invocation of the reset callback.
I can't find an explanation why this is needed. There was a comment
saying
| * We want to perform per-engine reset from atomic context (e.g.
| * softirq), which imposes the constraint that we cannot sleep.
but it does not state the problem with being preempted while waiting for
the reset. The commit itself does not explain why an atomic reset is
needed, it just states that it is a requirement now. On !RT we could
pull packets from a NICs and forward them other NICs for 2ms.
I've been looking over the reset callbacks and gen8_reset_engines() +
gen6_reset_engines() acquire a spinlock_t. Since this becomes a sleeping
lock on PREEMPT_RT it must not be acquired with disabled preemption.
i915_do_reset() acquires no lock but then has two udelay()s of 50us
each. Not good latency wise in a preempt-off section.
Could someone please explain why atomic is needed during reset, what
problems are introduced by a possible preemption?
Sebastian
next prev parent reply other threads:[~2023-06-30 13:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 0:57 [RFC] tentative fix for drm/i915/gt regression on preempt-rt Paul Gortmaker
2023-06-30 13:09 ` Sebastian Andrzej Siewior [this message]
2023-07-03 15:30 ` Tvrtko Ursulin
2023-07-03 16:12 ` Sebastian Andrzej Siewior
2023-07-04 8:02 ` Tvrtko Ursulin
2023-07-04 9:25 ` Sebastian Andrzej Siewior
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=20230630130949.coN0sVU4@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=chris@chris-wilson.co.uk \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=rodrigo.vivi@intel.com \
--cc=tglx@linutronix.de \
--cc=tvrtko.ursulin@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;
as well as URLs for NNTP newsgroup(s).