Messages in this thread | | | Date | Tue, 1 Oct 2013 09:33:01 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] rwsem: reduce spinlock contention in wakeup code path |
| |
* 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
| |