Messages in this thread | | | Date | Fri, 4 Jul 2014 09:49:01 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC] Cancellable MCS spinlock rework |
| |
On Thu, Jul 03, 2014 at 01:51:48PM -0700, Jason Low wrote: > On Thu, 2014-07-03 at 16:35 -0400, Waiman Long wrote: > > On 07/03/2014 02:34 PM, Jason Low wrote: > > > On Thu, 2014-07-03 at 10:09 -0700, Davidlohr Bueso wrote: > > >> On Thu, 2014-07-03 at 09:31 +0200, Peter Zijlstra wrote: > > >>> On Wed, Jul 02, 2014 at 10:30:03AM -0700, Jason Low wrote: > > >>>> Would potentially reducing the size of the rw semaphore structure by 32 > > >>>> bits (for all architectures using optimistic spinning) be a nice > > >>>> benefit? > > >>> Possibly, although I had a look at the mutex structure and we didn't > > >>> have a hole to place it in, unlike what you found with the rwsem. > > >> Yeah, and currently struct rw_semaphore is the largest lock we have in > > >> the kernel. Shaving off space is definitely welcome. > > > Right, especially if it could help things like xfs inode. > > > > > > > I do see a point in reducing the size of the rwsem structure. However, I > > don't quite understand the point of converting pointers in the > > optimistic_spin_queue structure to atomic_t. > > Converting the pointers in the optimistic_spin_queue to atomic_t would > mean we're fully operating on atomic operations instead of using the > potentially racy cmpxchg + ACCESS_ONCE stores on the pointers. > > If we're in the process of using the CPU numbers in atomic_t, I thought > we might as well fix that as well since it has actually been shown to > result in lockups on some architectures. We can then avoid needing to > implement the tricky architecture workarounds for optimistic spinning. > Wouldn't that be a "nice-have"?
Nah, I think those archs are fundamentally broken at the moment, we should not make code harder to read and or more complex just for them. [unhandled content-type:application/pgp-signature] | |