Messages in this thread | | | Date | Tue, 01 Oct 2013 16:03:10 -0400 | From | Waiman Long <> | Subject | Re: [PATCH] rwsem: reduce spinlock contention in wakeup code path |
| |
On 10/01/2013 03:33 AM, Ingo Molnar wrote: > * Waiman Long<waiman.long@hp.com> wrote: > >>> I think Waiman's patches (even the later ones) made the queued rwlocks >>> be a side-by-side implementation with the old rwlocks, and I think >>> that was just being unnecessarily careful. It might be useful for >>> testing to have a config option to switch between the two, but we >>> might as well go all the way. >> It is not actually a side-by-side implementation. A user can choose >> either regular rwlock or the queue one, but never both by setting a >> configuration parameter. However, I now think that maybe we should do it >> the lockref way by pre-determining it on a per-architecture level >> without user visible configuration option. > Well, as I pointed it out to you during review, such a Kconfig driven > locking API choice is a no-go! > > What I suggested instead: there's absolutely no problem with providing a > better rwlock_t implementation, backed with numbers and all that. > > Thanks, > > Ingo
Yes, this is what I am planning to do. The next version of my qrwlock patch will force the switch to queue rwlock for x86 architecture. The other architectures have to be done separately.
-Longman
| |