On Wed, Apr 17, 2013 at 09:08:17PM +0200, Daniel Vetter wrote: > On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: > >> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: > >> > The thing is now that you're not expected to hold these locks for a > >> > long > >> > time - if you need to synchronously stall while holding a lock > >> > performance > >> > will go down the gutters anyway. And since most current > >> > gpus/co-processors > >> > still can't really preempt fairness isn't that high a priority, > >> > either. > >> > So we didn't think too much about that. > >> > >> Yeah but you're proposing a new synchronization primitive for the core > >> kernel.. all such 'fun' details need to be considered, not only those > >> few that bear on the one usecase. > > > > Which bares the question, what other use cases are there? > > Just stumbled over one I think: If we have a big graph of connected > things (happens really often for video pipelines). And we want > multiple users to use them in parallel. But sometimes a configuration > change could take way too long and so would unduly stall a 2nd thread > with just a global mutex, then per-object ww_mutexes would be a fit: > You'd start with grabbing all the locks for the objects you want to > change anything with, then grab anything in the graph that you also > need to check. Thanks to loop detection and self-recursion this would > all nicely work out, even for cyclic graphs of objects. Indeed, that would make the locking for atomic modeset/page flip very easy to handle, while still allowing the use of suitable fine grained locks. I like the idea. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
