On Thu, Feb 13, 2014 at 05:35:46PM +0100, Peter Zijlstra wrote: > On Tue, Feb 11, 2014 at 03:12:59PM -0500, Waiman Long wrote: > > Using the same locktest program to repetitively take a single rwlock with > > programmable number of threads and count their execution times. Each > > thread takes the lock 5M times on a 4-socket 40-core Westmere-EX > > system. I bound all the threads to different CPUs with the following > > 3 configurations: > > > > 1) Both CPUs and lock are in the same node > > 2) CPUs and lock are in different nodes > > 3) Half of the CPUs are in same node as the lock & the other half > > are remote > > I can't find these configurations in the below numbers; esp the first is > interesting because most computers out there have no nodes. > > > Two types of qrwlock are tested: > > 1) Use MCS lock > > 2) Use ticket lock > > arch_spinlock_t; you forget that if you change that to an MCS style lock > this one goes along for free.
Furthermore; comparing the current rwlock to the ticket-rwlock already shows an improvement, so on that aspect its worth it as well. And there's also the paravirt people to consider; a fair rwlock will make them unhappy; and I'm hoping that their current paravirt ticket stuff is sufficient to deal with the ticket-rwlock without them having to come and wreck things again. Similarly; qspinlock needs paravirt support. -- 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/
