On Sat, Feb 25, 2017 at 12:36 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > 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. ohh, that would be spiffy BR, -R -- 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
