[Intel-gfx] [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping

[Simon Farnsworth]

On Thursday 1 November 2012 09:58:51 Jesse Barnes wrote:
> On Thu, 01 Nov 2012 16:52:05 +0000
> Tvrtko Ursulin <tvrtko.ursulin at onelan.co.uk> wrote:
> 
> > On Thursday 01 November 2012 16:20:03 Chris Wilson wrote:
> > > On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes <jbarnes at virtuousgeek.org> 
> > wrote:
> > > > On Thu, 01 Nov 2012 15:52:23 +0000
> > > > 
> > > > Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > > > Actually I've justified the blocking here to myself, and prefer it to
> > > > > simply running the crtc->unpin_work. If userspace is swamping the system
> > > > > so badly that we can run the kthreads quick enough, it deserves a stall.
> > > > > Note that the unpin leak is still about the 3rd most common bug in
> > > > > fedora,
> > > > > so this stall will be forced on many machines.
> > > > 
> > > > Hm funky, why does Fedora hit it so much?  Does some of the GNOME shell
> > > > stuff run unthrottled or something?
> > > 
> > > I don't think so. I trust that in Tvrtko's use case, he is not so much as
> > > hogging the GPU as keeping the system as a whole relatively busy. So I
> > > suspect it is more to do with CPU starvation of the kthreads than
> > > anything else.
> > > 
> > > Tvrtko, do you have any feeling for why your machine was easily
> > > suspectible to this leak? Are the stalls noticeable and do they affect
> > > your performance targets?
> > 
> > We didn't bother looking for any stalls, but for a long time we were 
> > occasionally hitting this pin_count BUG i915_gem_object_pin. So it didn't in 
> > fact affect our performance targets as much it completely wrecked our system.
> > 
> > If this patch causes an occasional stall instead, given that this bug triggers 
> > every 3-4 hours of uptime, we are fine with that. If a frame or so is missed 
> > every couple hours on low end hardware we don't care that much.
> > 
> > More on the actual workload...
> > 
> > Only recently we got lucky and found a platform and workload where it happens 
> > reliably. And this patch reliably fixes that.
> > 
> > In this workload CPU is being loaded 50-60% decoding a movie and rendering it 
> > to a full screen window. Our proprietary compositor page flips at 60Hz only, 
> > not faster. Together with another small semi-transparent window being rendered 
> > on top of the full screen movie. Movie played is a 25fps one, which means the 
> > full screen window is damaged 25 out of 60 frames (give or take) which is when 
> > we render to our back buffer and page flip at the vsync rate (60Hz).
> > 
> > According to intel_gpu_top tool, GPU load is roughly at 40%, apart from the 
> > "Framebuffer Compression" metric which is maxed out, if that is one is at all 
> > valid.
> > 
> > This particular scenario triggers the bug only on two of our Atom based 
> > platform both with a NM10/Pineview G/i915 chipset.
> 
> Ah ok on Atom you're probably CPU constrained a bit, but still at
> 50-60% utilization the kthreads should be running at least sometimes...
> 
> But it sounds like a case of the kthreads not running instead of
> queueing too fast anyway (not that the latter is really possible
> without some hacking to the flip code).
> 
It may help you here to know that we run both our compositor and the X server
at real-time priorities - both are SCHED_RR static priority 1 (the lowest
realtime priority). IIRC, the kthreads run at SCHED_OTHER priority, so we are
quite capable of starving them during a burst of activity.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20121105/cdce3514/attachment.sig>