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. -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-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
