Messages in this thread | | | Date | Wed, 11 Dec 2013 10:03:00 -0500 | From | Waiman Long <> | Subject | Re: [PATCH] mutexes: Add CONFIG_DEBUG_MUTEX_FASTPATH=y debug variant to debug SMP races |
| |
On 12/03/2013 03:52 AM, Ingo Molnar wrote: > * > I think we try that, to make mutexes safer in general. > > Can you see a way to do that fairly cheaply? > > I can see two approaches, both rather radical: > > 1) > > Eliminate mutex->count and (ab-)use mutex->wait_lock as 'the' mutex > lock: with TICKET_SLOWPATH_FLAG used to denote waiters or so and care > taken to not use it as a 'real' spinlock but use the raw accessors. > > This would still allow a good mutex_lock() fastpath, as it would > essentially become spin_trylock() with an asm goto slow path helper > perhaps. > > Doing this would have various advantages: > > - we'd eliminate much (all?) of per arch mutex code > - we'd share spinlock and mutex low level implementations > - we'd reduce struct mutex size by 4 bytes > > It's still early in the morning so I might be missing something > trivial though - this sounds suspiciously too easy ;-) Having a proper > mutex slowpath might not be so easy without changing the spinlock > code. > > 2) > > Another method would be to do the opposite: eliminate mutex->wait_lock > [for the non-debug case] and do everything via mutex->count and > mutex->owner. > > This saves even more space and potentially enables a tighter slowpath. > > It probably won't hurt the massively parallel case, as we already do > smart MCS locking via mutex->spin_mlock. > > So I'd argue for #2. (Assuming it addresses the problem) > > Thanks, > > Ingo > >
I also think that #2 is safer as messing with spinlock code can be risky. However, #2 probably won't work for architectures that use the generic mutex-xchg.h fastpath. Currently the following architectures use mutex-xchg.h - unicore32, arc, arm and hexagon. Is there a reason why they cannot be converted to use mutex-dec.h instead?
-Longman
| |