On Mon, Jun 10, 2013 at 05:51:14PM -0700, Linus Torvalds wrote: > On Mon, Jun 10, 2013 at 5:44 PM, Steven Rostedt <rost...@goodmis.org> wrote: > > > > OK, I haven't found a issue here yet, but youss are beiing trickssy! We > > don't like trickssy, and we must find precccciouss!!!
Heh! You should see what it looks like if you make slightly different design decisions. For example, just you try switching back from queued to ticket mode while there are still CPUs spinning on the lock! ;-) > .. and I personally have my usual reservations. I absolutely hate > papering over scalability issues, and historically whenever people > have ever thought that we want complex spinlocks, the problem has > always been that the locking sucks. > > So reinforced by previous events, I really feel that code that needs > this kind of spinlock is broken and needs to be fixed, rather than > actually introduce tricky spinlocks. If the only effect of this patch submission is to give people a bit more motivation to solve the underlying lock-contention problems, I am happy. > So in order to merge something like this, I want (a) numbers for real > loads and (b) explanations for why the spinlock users cannot be fixed. > > Because "we might hit loads" is just not good enough. I would counter > with "hiding problems causes more of them". Agreed. As I said in the first paragraph of the commit log: ... if we must have high-contention locks, why not make them automatically switch between light-weight ticket locks at low contention and queued locks at high contention? The reason that I created this patch was that I was seeing people arguing for locks optimized for high contention, and the ones that I saw required the developer to predict which locks would encounter high levels of contention. Changes in workloads would of course invalidate those predictions. But again, if the only effect of this patch submission is to give people a bit more motivation to solve the underlying lock-contention problems, I am happy. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/