On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt 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? Tbh I don't see any other either - but I agree with Peter and thinking things through and making the api a bit more generic seems to help in clarifying the semantics. Reminds me that I still need to draw a few diagrams ;-) -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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
