On Thursday 1 November 2012 09:58:51 Jesse Barnes wrote: > On Thu, 01 Nov 2012 16:52:05 +0000 > Tvrtko Ursulin <[email protected]> wrote: > > > On Thursday 01 November 2012 16:20:03 Chris Wilson wrote: > > > On Thu, 1 Nov 2012 09:04:02 -0700, Jesse Barnes > > > <[email protected]> > > wrote: > > > > On Thu, 01 Nov 2012 15:52:23 +0000 > > > > > > > > Chris Wilson <[email protected]> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
