On Sat, Feb 25, 2017 at 4:43 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: > Probably a symptom of needing finer grained locking, but if we wait on > the incoming fence-fd (which could come from a different context) while > holding struct_mutex, that blocks retire_worker so gpu fences cannot get > scheduled. > > This causes a problem if userspace manages to get more than a frame > ahead, leaving the atomic-commit worker blocked waiting on fences that > cannot be signaled because submit is blocked waiting for a fence > signalled from vblank (after the atomic commit which is blocked). > > If we start having multiple fence ctxs for the gpu, submit_fence_sync() > would probably need to move outside of struct_mutex as well. > > Signed-off-by: Rob Clark <robdclark@xxxxxxxxx> It's unfortunately not yet landed, but as soon as it's there I think we should annotate fences using the cross-release stuff that's cooking: https://lwn.net/Articles/708628/ That should be able to catch deps between waiter/signaller vs. locking. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
