[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b244f88e85a44485be9038c622fa13b1@AcuMS.aculab.com>
Date: Mon, 18 Jul 2022 15:50:06 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Mauro Carvalho Chehab' <mauro.chehab@...ux.intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
CC: Mauro Carvalho Chehab <mchehab@...nel.org>,
David Airlie <airlied@...ux.ie>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
Chris Wilson <chris.p.wilson@...el.com>,
Matthew Auld <matthew.auld@...el.com>,
Dave Airlie <airlied@...hat.com>,
Thomas Hellström
<thomas.hellstrom@...ux.intel.com>,
Lucas De Marchi <lucas.demarchi@...el.com>,
"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [Intel-gfx] [PATCH v2 01/21] drm/i915/gt: Ignore TLB
invalidations on idle engines
From: Mauro Carvalho Chehab
> Sent: 18 July 2022 15:54
>
> On Mon, 18 Jul 2022 14:16:10 +0100
> Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com> wrote:
>
> > On 14/07/2022 13:06, Mauro Carvalho Chehab wrote:
> > > From: Chris Wilson <chris.p.wilson@...el.com>
> > >
> > > 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@...r.kernel.org
> > > 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.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists