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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
