> On Mon, Nov 11, 2013 at 09:17:52PM +0000, Tim Chen wrote: >> An alternate implementation is >> while (!ACCESS_ONCE(node->locked)) >> arch_mutex_cpu_relax(); >> smp_load_acquire(&node->locked); >> >> Leaving the smp_load_acquire at the end to provide appropriate barrier. >> Will that be acceptable?
Will Deacon <will.dea...@arm.com> wrote: > It still doesn't solve my problem though: I want a way to avoid that busy > loop by some architecture-specific manner. The arch_mutex_cpu_relax() hook > is a start, but there is no corresponding hook on the unlock side to issue a > wakeup. Given a sensible relax implementation, I don't have an issue with > putting a load-acquire in a loop, since it shouldn't be aggresively spinning > anymore. So you want something like this? /* * This is a spin-wait with acquire semantics. That is, accesses after * this are not allowed to be reordered before the load that meets * the specified condition. This requires that it end with either a * load-acquire or a full smp_mb(). The optimal way to do this is likely * to be architecture-dependent. E.g. x86 MONITOR/MWAIT instructions. */ #ifndef smp_load_acquire_until #define smp_load_acquire_until(addr, cond) \ while (!(smp_load_acquire(addr) cond)) { \ do { \ arch_mutex_cpu_relax(); \ } while (!(ACCESS_ONCE(*(addr)) cond)); \ } #endif smp_load_acquire_until(&node->locked, != 0); Alternative implementations: #define smp_load_acquire_until(addr, cond) { \ while (!(ACCESS_ONCE(*(addr)) cond)) \ arch_mutex_cpu_relax(); \ smp_mb(); } #define smp_load_acquire_until(addr, cond) \ if (!(smp_load_acquire(addr) cond)) { \ do { \ arch_mutex_cpu_relax(); \ } while (!(ACCESS_ONCE(*(addr)) cond)); \ smp_mb(); \ } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/