Hi David,
On 18/07/2022 16:50, David Laight wrote:
From: Mauro Carvalho Chehab
Sent: 18 July 2022 15:54
On Mon, 18 Jul 2022 14:16:10 +0100
Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
From: Chris Wilson <chris.p.wilson@xxxxxxxxx>
Check if the device is powered down prior to any engine activity,
as, on such cases, all the TLBs were already invalidated, so an
explicit TLB invalidation is not needed, thus reducing the
performance regression impact due to it.
This becomes more significant with GuC, as it can only do so when
the connection to the GuC is awake.
Cc: stable@xxxxxxxxxxxxxxx
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Patch itself looks fine but I don't think we closed on the issue of
stable/fixes on this patch?
No, because TLB cache invalidation takes time and causes time outs, which
in turn affects applications and produce Kernel warnings.
It's not only the TLB flushes that cause grief.
There is a loop that forces a write-back of all the frame buffer pages.
With a large display and some cpu (like my Ivy bridge one) that
takes long enough with pre-emption disabled that wakeup of RT processes
(and any pinned to the cpu) takes far longer than one might have
wished for.
Since some X servers request a flush every few seconds this makes
the system unusable for some workloads.
Ok TLB invalidations as discussed in this patch does not apply to
Ivybridge. But what is the write back loop you mention which is causing
you grief? What size frame buffers are we talking about here? If they
don't fit in the mappable area recently we merged a patch* which
improves things in that situation but not sure you are hitting exactly that.
Regards,
Tvrtko
*) 230523ba24bd ("drm/i915/gem: Don't evict unmappable VMAs when pinning
with PIN_MAPPABLE (v2)")
