Messages in this thread |  | | Date | Thu, 13 Feb 2014 18:26:57 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 7/8] locking: Introduce qrwlock |
| |
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.
|  |