Re: [PATCH RFC ticketlock] Auto-queued ticketlock

[Paul E. McKenney]

On Mon, Jun 10, 2013 at 05:51:14PM -0700, Linus Torvalds wrote:
> On Mon, Jun 10, 2013 at 5:44 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/