From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id 6B1C76B0108 for ; Wed, 6 Nov 2013 16:37:03 -0500 (EST) Received: by mail-pa0-f49.google.com with SMTP id lj1so269624pab.22 for ; Wed, 06 Nov 2013 13:37:03 -0800 (PST) Received: from psmtp.com ([74.125.245.202]) by mx.google.com with SMTP id ws5si478056pab.238.2013.11.06.13.37.01 for ; Wed, 06 Nov 2013 13:37:01 -0800 (PST) Subject: [PATCH v3 0/4] MCS Lock: MCS lock code cleanup and optimizations From: Tim Chen References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:36:56 -0800 Message-ID: <1383773816.11046.352.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Tim Chen , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" In this patch series, we separated out the MCS lock code which was previously embedded in the mutex.c. This allows for easier reuse of MCS lock in other places like rwsem and qrwlock. We also did some micro optimizations and barrier cleanup. This patches were previously part of the rwsem optimization patch series but now we spearate them out. Tim Chen v3: 1. modified memory barriers to support non x86 architectures that have weak memory ordering. v2: 1. change export mcs_spin_lock as a GPL export symbol 2. corrected mcs_spin_lock to references Jason Low (2): MCS Lock: optimizations and extra comments MCS Lock: Barrier corrections Jason Low (2): MCS Lock: optimizations and extra comments MCS Lock: Barrier corrections Tim Chen (1): MCS Lock: Restructure the MCS lock defines and locking code into its own file Waiman Long (2): MCS Lock: Make mcs_spinlock.h includable in other files MCS Lock: Allow architecture specific memory barrier in lock/unlock arch/x86/include/asm/barrier.h | 6 +++ include/linux/mcs_spinlock.h | 25 ++++++++++ include/linux/mutex.h | 5 +- kernel/Makefile | 6 +- kernel/mcs_spinlock.c | 96 ++++++++++++++++++++++++++++++++++++++++ kernel/mutex.c | 60 +++---------------------- 6 files changed, 140 insertions(+), 58 deletions(-) create mode 100644 include/linux/mcs_spinlock.h create mode 100644 kernel/mcs_spinlock.c -- 1.7.4.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by kanga.kvack.org (Postfix) with ESMTP id C9BCE6B010A for ; Wed, 6 Nov 2013 16:37:22 -0500 (EST) Received: by mail-pa0-f50.google.com with SMTP id fb1so265587pad.23 for ; Wed, 06 Nov 2013 13:37:22 -0800 (PST) Received: from psmtp.com ([74.125.245.163]) by mx.google.com with SMTP id ph6si99209pbb.337.2013.11.06.13.37.20 for ; Wed, 06 Nov 2013 13:37:21 -0800 (PST) Subject: [PATCH v3 5/5] MCS Lock: Allow architecture specific memory barrier in lock/unlock From: Tim Chen In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:37:16 -0800 Message-ID: <1383773836.11046.357.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Tim Chen , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" This patch moves the decision of what kind of memory barriers to be used in the MCS lock and unlock functions to the architecture specific layer. It also moves the actual lock/unlock code to mcs_spinlock.c file. A full memory barrier will be used if the following macros are not defined: 1) smp_mb__before_critical_section() 2) smp_mb__after_critical_section() For the x86 architecture, only compiler barrier will be needed. Signed-off-by: Waiman Long Signed-off-by: Tim Chen --- arch/x86/include/asm/barrier.h | 6 +++ include/linux/mcs_spinlock.h | 78 +------------------------------------- kernel/mcs_spinlock.c | 81 ++++++++++++++++++++++++++++++++++++++- 3 files changed, 86 insertions(+), 79 deletions(-) diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h index c6cd358..6d0172c 100644 --- a/arch/x86/include/asm/barrier.h +++ b/arch/x86/include/asm/barrier.h @@ -92,6 +92,12 @@ #endif #define smp_read_barrier_depends() read_barrier_depends() #define set_mb(var, value) do { (void)xchg(&var, value); } while (0) + +#if !defined(CONFIG_X86_PPRO_FENCE) && !defined(CONFIG_X86_OOSTORE) +# define smp_mb__before_critical_section() barrier() +# define smp_mb__after_critical_section() barrier() +#endif + #else #define smp_mb() barrier() #define smp_rmb() barrier() diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h index f2c71e8..d54bb23 100644 --- a/include/linux/mcs_spinlock.h +++ b/include/linux/mcs_spinlock.h @@ -12,19 +12,6 @@ #ifndef __LINUX_MCS_SPINLOCK_H #define __LINUX_MCS_SPINLOCK_H -/* - * asm/processor.h may define arch_mutex_cpu_relax(). - * If it is not defined, cpu_relax() will be used. - */ -#include -#include -#include -#include - -#ifndef arch_mutex_cpu_relax -# define arch_mutex_cpu_relax() cpu_relax() -#endif - struct mcs_spinlock { struct mcs_spinlock *next; int locked; /* 1 if lock acquired */ @@ -32,68 +19,7 @@ struct mcs_spinlock { extern void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node); - -/* - * In order to acquire the lock, the caller should declare a local node and - * pass a reference of the node to this function in addition to the lock. - * If the lock has already been acquired, then this will proceed to spin - * on this node->locked until the previous lock holder sets the node->locked - * in mcs_spin_unlock(). - * - * The _raw_mcs_spin_lock() function should not be called directly. Instead, - * users should call mcs_spin_lock(). - */ -static inline -void _raw_mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) -{ - struct mcs_spinlock *prev; - - /* Init node */ - node->locked = 0; - node->next = NULL; - - /* xchg() provides a memory barrier */ - prev = xchg(lock, node); - if (likely(prev == NULL)) { - /* Lock acquired */ - return; - } - ACCESS_ONCE(prev->next) = node; - /* Wait until the lock holder passes the lock down */ - while (!ACCESS_ONCE(node->locked)) - arch_mutex_cpu_relax(); - - /* Make sure subsequent operations happen after the lock is acquired */ - smp_rmb(); -} - -/* - * Releases the lock. The caller should pass in the corresponding node that - * was used to acquire the lock. - */ -static inline -void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) -{ - struct mcs_spinlock *next = ACCESS_ONCE(node->next); - - if (likely(!next)) { - /* - * cmpxchg() provides a memory barrier. - * Release the lock by setting it to NULL - */ - if (likely(cmpxchg(lock, node, NULL) == node)) - return; - /* Wait until the next pointer is set */ - while (!(next = ACCESS_ONCE(node->next))) - arch_mutex_cpu_relax(); - } else { - /* - * Make sure all operations within the critical section - * happen before the lock is released. - */ - smp_wmb(); - } - ACCESS_ONCE(next->locked) = 1; -} +extern +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node); #endif /* __LINUX_MCS_SPINLOCK_H */ diff --git a/kernel/mcs_spinlock.c b/kernel/mcs_spinlock.c index 3c55626..2dfd207 100644 --- a/kernel/mcs_spinlock.c +++ b/kernel/mcs_spinlock.c @@ -7,15 +7,90 @@ * It avoids expensive cache bouncings that common test-and-set spin-lock * implementations incur. */ +/* + * asm/processor.h may define arch_mutex_cpu_relax(). + * If it is not defined, cpu_relax() will be used. + */ +#include +#include +#include +#include #include #include +#ifndef arch_mutex_cpu_relax +# define arch_mutex_cpu_relax() cpu_relax() +#endif + /* - * We don't inline mcs_spin_lock() so that perf can correctly account for the - * time spent in this lock function. + * Fall back to use full memory barrier if those macros are not defined + * in a architecture specific header file. + */ +#ifndef smp_mb__before_critical_section +#define smp_mb__before_critical_section() smp_mb() +#endif + +#ifndef smp_mb__after_critical_section +#define smp_mb__after_critical_section() smp_mb() +#endif + + +/* + * In order to acquire the lock, the caller should declare a local node and + * pass a reference of the node to this function in addition to the lock. + * If the lock has already been acquired, then this will proceed to spin + * on this node->locked until the previous lock holder sets the node->locked + * in mcs_spin_unlock(). */ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) { - _raw_mcs_spin_lock(lock, node); + struct mcs_spinlock *prev; + + /* Init node */ + node->locked = 0; + node->next = NULL; + + /* xchg() provides a memory barrier */ + prev = xchg(lock, node); + if (likely(prev == NULL)) { + /* Lock acquired */ + return; + } + ACCESS_ONCE(prev->next) = node; + /* Wait until the lock holder passes the lock down */ + while (!ACCESS_ONCE(node->locked)) + arch_mutex_cpu_relax(); + + /* Make sure subsequent operations happen after the lock is acquired */ + smp_mb__before_critical_section(); } EXPORT_SYMBOL_GPL(mcs_spin_lock); + +/* + * Releases the lock. The caller should pass in the corresponding node that + * was used to acquire the lock. + */ +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) +{ + struct mcs_spinlock *next = ACCESS_ONCE(node->next); + + if (likely(!next)) { + /* + * cmpxchg() provides a memory barrier. + * Release the lock by setting it to NULL + */ + if (likely(cmpxchg(lock, node, NULL) == node)) + return; + /* Wait until the next pointer is set */ + while (!(next = ACCESS_ONCE(node->next))) + arch_mutex_cpu_relax(); + } else { + /* + * Make sure all operations within the critical section + * happen before the lock is released. + */ + smp_mb__after_critical_section(); + } + ACCESS_ONCE(next->locked) = 1; +} +EXPORT_SYMBOL_GPL(mcs_spin_unlock); -- 1.7.4.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by kanga.kvack.org (Postfix) with ESMTP id B25A96B010C for ; Wed, 6 Nov 2013 16:37:43 -0500 (EST) Received: by mail-pb0-f48.google.com with SMTP id mc8so99688pbc.21 for ; Wed, 06 Nov 2013 13:37:43 -0800 (PST) Received: from psmtp.com ([74.125.245.135]) by mx.google.com with SMTP id ai2si465875pad.291.2013.11.06.13.37.40 for ; Wed, 06 Nov 2013 13:37:42 -0800 (PST) Subject: [PATCH v3 1/5] MCS Lock: Restructure the MCS lock defines and locking code into its own file From: Tim Chen In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:37:01 -0800 Message-ID: <1383773821.11046.353.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Tim Chen , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" We will need the MCS lock code for doing optimistic spinning for rwsem. Extracting the MCS code from mutex.c and put into its own file allow us to reuse this code easily for rwsem. Signed-off-by: Tim Chen Signed-off-by: Davidlohr Bueso --- include/linux/mcs_spinlock.h | 64 ++++++++++++++++++++++++++++++++++++++++++ include/linux/mutex.h | 5 ++- kernel/mutex.c | 60 ++++---------------------------------- 3 files changed, 74 insertions(+), 55 deletions(-) create mode 100644 include/linux/mcs_spinlock.h diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h new file mode 100644 index 0000000..b5de3b0 --- /dev/null +++ b/include/linux/mcs_spinlock.h @@ -0,0 +1,64 @@ +/* + * MCS lock defines + * + * This file contains the main data structure and API definitions of MCS lock. + * + * The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spin-lock + * with the desirable properties of being fair, and with each cpu trying + * to acquire the lock spinning on a local variable. + * It avoids expensive cache bouncings that common test-and-set spin-lock + * implementations incur. + */ +#ifndef __LINUX_MCS_SPINLOCK_H +#define __LINUX_MCS_SPINLOCK_H + +struct mcs_spinlock { + struct mcs_spinlock *next; + int locked; /* 1 if lock acquired */ +}; + +/* + * We don't inline mcs_spin_lock() so that perf can correctly account for the + * time spent in this lock function. + */ +static noinline +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) +{ + struct mcs_spinlock *prev; + + /* Init node */ + node->locked = 0; + node->next = NULL; + + prev = xchg(lock, node); + if (likely(prev == NULL)) { + /* Lock acquired */ + node->locked = 1; + return; + } + ACCESS_ONCE(prev->next) = node; + smp_wmb(); + /* Wait until the lock holder passes the lock down */ + while (!ACCESS_ONCE(node->locked)) + arch_mutex_cpu_relax(); +} + +static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) +{ + struct mcs_spinlock *next = ACCESS_ONCE(node->next); + + if (likely(!next)) { + /* + * Release the lock by setting it to NULL + */ + if (cmpxchg(lock, node, NULL) == node) + return; + /* Wait until the next pointer is set */ + while (!(next = ACCESS_ONCE(node->next))) + arch_mutex_cpu_relax(); + } + ACCESS_ONCE(next->locked) = 1; + smp_wmb(); +} + +#endif /* __LINUX_MCS_SPINLOCK_H */ diff --git a/include/linux/mutex.h b/include/linux/mutex.h index bab49da..32a32e6 100644 --- a/include/linux/mutex.h +++ b/include/linux/mutex.h @@ -46,6 +46,7 @@ * - detects multi-task circular deadlocks and prints out all affected * locks and tasks (and only those tasks) */ +struct mcs_spinlock; struct mutex { /* 1: unlocked, 0: locked, negative: locked, possible waiters */ atomic_t count; @@ -55,7 +56,7 @@ struct mutex { struct task_struct *owner; #endif #ifdef CONFIG_MUTEX_SPIN_ON_OWNER - void *spin_mlock; /* Spinner MCS lock */ + struct mcs_spinlock *mcs_lock; /* Spinner MCS lock */ #endif #ifdef CONFIG_DEBUG_MUTEXES const char *name; @@ -179,4 +180,4 @@ extern int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); # define arch_mutex_cpu_relax() cpu_relax() #endif -#endif +#endif /* __LINUX_MUTEX_H */ diff --git a/kernel/mutex.c b/kernel/mutex.c index d24105b..e08b183 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -25,6 +25,7 @@ #include #include #include +#include /* * In the DEBUG case we are using the "NULL fastpath" for mutexes, @@ -52,7 +53,7 @@ __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key) INIT_LIST_HEAD(&lock->wait_list); mutex_clear_owner(lock); #ifdef CONFIG_MUTEX_SPIN_ON_OWNER - lock->spin_mlock = NULL; + lock->mcs_lock = NULL; #endif debug_mutex_init(lock, name, key); @@ -111,54 +112,7 @@ EXPORT_SYMBOL(mutex_lock); * more or less simultaneously, the spinners need to acquire a MCS lock * first before spinning on the owner field. * - * We don't inline mspin_lock() so that perf can correctly account for the - * time spent in this lock function. */ -struct mspin_node { - struct mspin_node *next ; - int locked; /* 1 if lock acquired */ -}; -#define MLOCK(mutex) ((struct mspin_node **)&((mutex)->spin_mlock)) - -static noinline -void mspin_lock(struct mspin_node **lock, struct mspin_node *node) -{ - struct mspin_node *prev; - - /* Init node */ - node->locked = 0; - node->next = NULL; - - prev = xchg(lock, node); - if (likely(prev == NULL)) { - /* Lock acquired */ - node->locked = 1; - return; - } - ACCESS_ONCE(prev->next) = node; - smp_wmb(); - /* Wait until the lock holder passes the lock down */ - while (!ACCESS_ONCE(node->locked)) - arch_mutex_cpu_relax(); -} - -static void mspin_unlock(struct mspin_node **lock, struct mspin_node *node) -{ - struct mspin_node *next = ACCESS_ONCE(node->next); - - if (likely(!next)) { - /* - * Release the lock by setting it to NULL - */ - if (cmpxchg(lock, node, NULL) == node) - return; - /* Wait until the next pointer is set */ - while (!(next = ACCESS_ONCE(node->next))) - arch_mutex_cpu_relax(); - } - ACCESS_ONCE(next->locked) = 1; - smp_wmb(); -} /* * Mutex spinning code migrated from kernel/sched/core.c @@ -448,7 +402,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, for (;;) { struct task_struct *owner; - struct mspin_node node; + struct mcs_spinlock node; if (use_ww_ctx && ww_ctx->acquired > 0) { struct ww_mutex *ww; @@ -470,10 +424,10 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, * If there's an owner, wait for it to either * release the lock or go to sleep. */ - mspin_lock(MLOCK(lock), &node); + mcs_spin_lock(&lock->mcs_lock, &node); owner = ACCESS_ONCE(lock->owner); if (owner && !mutex_spin_on_owner(lock, owner)) { - mspin_unlock(MLOCK(lock), &node); + mcs_spin_unlock(&lock->mcs_lock, &node); goto slowpath; } @@ -488,11 +442,11 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, } mutex_set_owner(lock); - mspin_unlock(MLOCK(lock), &node); + mcs_spin_unlock(&lock->mcs_lock, &node); preempt_enable(); return 0; } - mspin_unlock(MLOCK(lock), &node); + mcs_spin_unlock(&lock->mcs_lock, &node); /* * When there's no owner, we might have preempted between the -- 1.7.4.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by kanga.kvack.org (Postfix) with ESMTP id 063C56B010D for ; Wed, 6 Nov 2013 16:37:44 -0500 (EST) Received: by mail-pd0-f181.google.com with SMTP id x10so96503pdj.26 for ; Wed, 06 Nov 2013 13:37:44 -0800 (PST) Received: from psmtp.com ([74.125.245.131]) by mx.google.com with SMTP id hb3si511410pac.94.2013.11.06.13.37.42 for ; Wed, 06 Nov 2013 13:37:43 -0800 (PST) Subject: [PATCH v3 2/5] MCS Lock: optimizations and extra comments From: Tim Chen In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:37:04 -0800 Message-ID: <1383773824.11046.354.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Tim Chen , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" Remove unnecessary operation and make the cmpxchg(lock, node, NULL) == node check in mcs_spin_unlock() likely() as it is likely that a race did not occur most of the time. Also add in more comments describing how the local node is used in MCS locks. Reviewed-by: Tim Chen Signed-off-by: Jason Low Signed-off-by: Tim Chen --- include/linux/mcs_spinlock.h | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h index b5de3b0..96f14299 100644 --- a/include/linux/mcs_spinlock.h +++ b/include/linux/mcs_spinlock.h @@ -18,6 +18,12 @@ struct mcs_spinlock { }; /* + * In order to acquire the lock, the caller should declare a local node and + * pass a reference of the node to this function in addition to the lock. + * If the lock has already been acquired, then this will proceed to spin + * on this node->locked until the previous lock holder sets the node->locked + * in mcs_spin_unlock(). + * * We don't inline mcs_spin_lock() so that perf can correctly account for the * time spent in this lock function. */ @@ -33,7 +39,6 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) prev = xchg(lock, node); if (likely(prev == NULL)) { /* Lock acquired */ - node->locked = 1; return; } ACCESS_ONCE(prev->next) = node; @@ -43,6 +48,10 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) arch_mutex_cpu_relax(); } +/* + * Releases the lock. The caller should pass in the corresponding node that + * was used to acquire the lock. + */ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) { struct mcs_spinlock *next = ACCESS_ONCE(node->next); @@ -51,7 +60,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod /* * Release the lock by setting it to NULL */ - if (cmpxchg(lock, node, NULL) == node) + if (likely(cmpxchg(lock, node, NULL) == node)) return; /* Wait until the next pointer is set */ while (!(next = ACCESS_ONCE(node->next))) -- 1.7.4.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by kanga.kvack.org (Postfix) with ESMTP id AC8DA6B010E for ; Wed, 6 Nov 2013 16:37:45 -0500 (EST) Received: by mail-pd0-f169.google.com with SMTP id q10so100802pdj.0 for ; Wed, 06 Nov 2013 13:37:45 -0800 (PST) Received: from psmtp.com ([74.125.245.135]) by mx.google.com with SMTP id ei3si97007pbc.350.2013.11.06.13.37.43 for ; Wed, 06 Nov 2013 13:37:44 -0800 (PST) Subject: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Tim Chen In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:37:07 -0800 Message-ID: <1383773827.11046.355.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Tim Chen , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" This patch corrects the way memory barriers are used in the MCS lock and removes ones that are not needed. Also add comments on all barriers. Reviewed-by: Tim Chen Signed-off-by: Jason Low Signed-off-by: Tim Chen --- include/linux/mcs_spinlock.h | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h index 96f14299..93d445d 100644 --- a/include/linux/mcs_spinlock.h +++ b/include/linux/mcs_spinlock.h @@ -36,16 +36,19 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) node->locked = 0; node->next = NULL; + /* xchg() provides a memory barrier */ prev = xchg(lock, node); if (likely(prev == NULL)) { /* Lock acquired */ return; } ACCESS_ONCE(prev->next) = node; - smp_wmb(); /* Wait until the lock holder passes the lock down */ while (!ACCESS_ONCE(node->locked)) arch_mutex_cpu_relax(); + + /* Make sure subsequent operations happen after the lock is acquired */ + smp_rmb(); } /* @@ -58,6 +61,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod if (likely(!next)) { /* + * cmpxchg() provides a memory barrier. * Release the lock by setting it to NULL */ if (likely(cmpxchg(lock, node, NULL) == node)) @@ -65,9 +69,14 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod /* Wait until the next pointer is set */ while (!(next = ACCESS_ONCE(node->next))) arch_mutex_cpu_relax(); + } else { + /* + * Make sure all operations within the critical section + * happen before the lock is released. + */ + smp_wmb(); } ACCESS_ONCE(next->locked) = 1; - smp_wmb(); } #endif /* __LINUX_MCS_SPINLOCK_H */ -- 1.7.4.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by kanga.kvack.org (Postfix) with ESMTP id 197D26B0111 for ; Wed, 6 Nov 2013 16:37:50 -0500 (EST) Received: by mail-pd0-f173.google.com with SMTP id r10so100219pdi.4 for ; Wed, 06 Nov 2013 13:37:49 -0800 (PST) Received: from psmtp.com ([74.125.245.163]) by mx.google.com with SMTP id pl10si102500pbc.328.2013.11.06.13.37.47 for ; Wed, 06 Nov 2013 13:37:48 -0800 (PST) Subject: [PATCH v3 4/5] MCS Lock: Make mcs_spinlock.h includable in other files From: Tim Chen In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:37:12 -0800 Message-ID: <1383773832.11046.356.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Tim Chen , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" The following changes are made to enable mcs_spinlock.h file to be widely included in other files without causing problem: 1) Include a number of prerequisite header files and define arch_mutex_cpu_relax(), if not previously defined. 2) Make mcs_spin_unlock() an inlined function and rename mcs_spin_lock() to _raw_mcs_spin_lock() which is also an inlined function. 3) Create a new mcs_spinlock.c file to contain the non-inlined mcs_spin_lock() function. Signed-off-by: Waiman Long Signed-off-by: Tim Chen --- include/linux/mcs_spinlock.h | 27 ++++++++++++++++++++++----- kernel/Makefile | 6 +++--- kernel/mcs_spinlock.c | 21 +++++++++++++++++++++ 3 files changed, 46 insertions(+), 8 deletions(-) create mode 100644 kernel/mcs_spinlock.c diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h index 93d445d..f2c71e8 100644 --- a/include/linux/mcs_spinlock.h +++ b/include/linux/mcs_spinlock.h @@ -12,11 +12,27 @@ #ifndef __LINUX_MCS_SPINLOCK_H #define __LINUX_MCS_SPINLOCK_H +/* + * asm/processor.h may define arch_mutex_cpu_relax(). + * If it is not defined, cpu_relax() will be used. + */ +#include +#include +#include +#include + +#ifndef arch_mutex_cpu_relax +# define arch_mutex_cpu_relax() cpu_relax() +#endif + struct mcs_spinlock { struct mcs_spinlock *next; int locked; /* 1 if lock acquired */ }; +extern +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node); + /* * In order to acquire the lock, the caller should declare a local node and * pass a reference of the node to this function in addition to the lock. @@ -24,11 +40,11 @@ struct mcs_spinlock { * on this node->locked until the previous lock holder sets the node->locked * in mcs_spin_unlock(). * - * We don't inline mcs_spin_lock() so that perf can correctly account for the - * time spent in this lock function. + * The _raw_mcs_spin_lock() function should not be called directly. Instead, + * users should call mcs_spin_lock(). */ -static noinline -void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) +static inline +void _raw_mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) { struct mcs_spinlock *prev; @@ -55,7 +71,8 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) * Releases the lock. The caller should pass in the corresponding node that * was used to acquire the lock. */ -static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) +static inline +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) { struct mcs_spinlock *next = ACCESS_ONCE(node->next); diff --git a/kernel/Makefile b/kernel/Makefile index 1ce4755..2ad8454 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -50,9 +50,9 @@ obj-$(CONFIG_SMP) += smp.o ifneq ($(CONFIG_SMP),y) obj-y += up.o endif -obj-$(CONFIG_SMP) += spinlock.o -obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o -obj-$(CONFIG_PROVE_LOCKING) += spinlock.o +obj-$(CONFIG_SMP) += spinlock.o mcs_spinlock.o +obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o mcs_spinlock.o +obj-$(CONFIG_PROVE_LOCKING) += spinlock.o mcs_spinlock.o obj-$(CONFIG_UID16) += uid16.o obj-$(CONFIG_MODULES) += module.o obj-$(CONFIG_MODULE_SIG) += module_signing.o modsign_pubkey.o modsign_certificate.o diff --git a/kernel/mcs_spinlock.c b/kernel/mcs_spinlock.c new file mode 100644 index 0000000..3c55626 --- /dev/null +++ b/kernel/mcs_spinlock.c @@ -0,0 +1,21 @@ +/* + * MCS lock + * + * The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spin-lock + * with the desirable properties of being fair, and with each cpu trying + * to acquire the lock spinning on a local variable. + * It avoids expensive cache bouncings that common test-and-set spin-lock + * implementations incur. + */ +#include +#include + +/* + * We don't inline mcs_spin_lock() so that perf can correctly account for the + * time spent in this lock function. + */ +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) +{ + _raw_mcs_spin_lock(lock, node); +} +EXPORT_SYMBOL_GPL(mcs_spin_lock); -- 1.7.4.4 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by kanga.kvack.org (Postfix) with ESMTP id DE24F6B0116 for ; Wed, 6 Nov 2013 16:41:40 -0500 (EST) Received: by mail-pb0-f44.google.com with SMTP id rp8so104827pbb.17 for ; Wed, 06 Nov 2013 13:41:40 -0800 (PST) Received: from psmtp.com ([74.125.245.147]) by mx.google.com with SMTP id ph6si156824pbb.97.2013.11.06.13.41.38 for ; Wed, 06 Nov 2013 13:41:39 -0800 (PST) Subject: Re: [PATCH v3 4/5] MCS Lock: Make mcs_spinlock.h includable in other files From: Tim Chen In-Reply-To: <1383773832.11046.356.camel@schen9-DESK> References: <1383773832.11046.356.camel@schen9-DESK> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:41:33 -0800 Message-ID: <1383774093.11046.358.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On Wed, 2013-11-06 at 13:37 -0800, Tim Chen wrote: > The following changes are made to enable mcs_spinlock.h file to be > widely included in other files without causing problem: > > 1) Include a number of prerequisite header files and define > arch_mutex_cpu_relax(), if not previously defined. > 2) Make mcs_spin_unlock() an inlined function and > rename mcs_spin_lock() to _raw_mcs_spin_lock() which is also an > inlined function. > 3) Create a new mcs_spinlock.c file to contain the non-inlined > mcs_spin_lock() function. > > Signed-off-by: Waiman Long > Signed-off-by: Tim Chen Should be Acked-by: Tim Chen > --- > include/linux/mcs_spinlock.h | 27 ++++++++++++++++++++++----- > kernel/Makefile | 6 +++--- > kernel/mcs_spinlock.c | 21 +++++++++++++++++++++ > 3 files changed, 46 insertions(+), 8 deletions(-) > create mode 100644 kernel/mcs_spinlock.c > > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h > index 93d445d..f2c71e8 100644 > --- a/include/linux/mcs_spinlock.h > +++ b/include/linux/mcs_spinlock.h > @@ -12,11 +12,27 @@ > #ifndef __LINUX_MCS_SPINLOCK_H > #define __LINUX_MCS_SPINLOCK_H > > +/* > + * asm/processor.h may define arch_mutex_cpu_relax(). > + * If it is not defined, cpu_relax() will be used. > + */ > +#include > +#include > +#include > +#include > + > +#ifndef arch_mutex_cpu_relax > +# define arch_mutex_cpu_relax() cpu_relax() > +#endif > + > struct mcs_spinlock { > struct mcs_spinlock *next; > int locked; /* 1 if lock acquired */ > }; > > +extern > +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node); > + > /* > * In order to acquire the lock, the caller should declare a local node and > * pass a reference of the node to this function in addition to the lock. > @@ -24,11 +40,11 @@ struct mcs_spinlock { > * on this node->locked until the previous lock holder sets the node->locked > * in mcs_spin_unlock(). > * > - * We don't inline mcs_spin_lock() so that perf can correctly account for the > - * time spent in this lock function. > + * The _raw_mcs_spin_lock() function should not be called directly. Instead, > + * users should call mcs_spin_lock(). > */ > -static noinline > -void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > +static inline > +void _raw_mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > { > struct mcs_spinlock *prev; > > @@ -55,7 +71,8 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > * Releases the lock. The caller should pass in the corresponding node that > * was used to acquire the lock. > */ > -static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > +static inline > +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > { > struct mcs_spinlock *next = ACCESS_ONCE(node->next); > > diff --git a/kernel/Makefile b/kernel/Makefile > index 1ce4755..2ad8454 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -50,9 +50,9 @@ obj-$(CONFIG_SMP) += smp.o > ifneq ($(CONFIG_SMP),y) > obj-y += up.o > endif > -obj-$(CONFIG_SMP) += spinlock.o > -obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o > -obj-$(CONFIG_PROVE_LOCKING) += spinlock.o > +obj-$(CONFIG_SMP) += spinlock.o mcs_spinlock.o > +obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock.o mcs_spinlock.o > +obj-$(CONFIG_PROVE_LOCKING) += spinlock.o mcs_spinlock.o > obj-$(CONFIG_UID16) += uid16.o > obj-$(CONFIG_MODULES) += module.o > obj-$(CONFIG_MODULE_SIG) += module_signing.o modsign_pubkey.o modsign_certificate.o > diff --git a/kernel/mcs_spinlock.c b/kernel/mcs_spinlock.c > new file mode 100644 > index 0000000..3c55626 > --- /dev/null > +++ b/kernel/mcs_spinlock.c > @@ -0,0 +1,21 @@ > +/* > + * MCS lock > + * > + * The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spin-lock > + * with the desirable properties of being fair, and with each cpu trying > + * to acquire the lock spinning on a local variable. > + * It avoids expensive cache bouncings that common test-and-set spin-lock > + * implementations incur. > + */ > +#include > +#include > + > +/* > + * We don't inline mcs_spin_lock() so that perf can correctly account for the > + * time spent in this lock function. > + */ > +void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > +{ > + _raw_mcs_spin_lock(lock, node); > +} > +EXPORT_SYMBOL_GPL(mcs_spin_lock); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by kanga.kvack.org (Postfix) with ESMTP id 8D4B86B0117 for ; Wed, 6 Nov 2013 16:42:08 -0500 (EST) Received: by mail-pb0-f53.google.com with SMTP id up7so103548pbc.26 for ; Wed, 06 Nov 2013 13:42:08 -0800 (PST) Received: from psmtp.com ([74.125.245.176]) by mx.google.com with SMTP id bc2si521762pad.100.2013.11.06.13.42.06 for ; Wed, 06 Nov 2013 13:42:06 -0800 (PST) Message-ID: <1383774119.13330.2.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH v3 0/4] MCS Lock: MCS lock code cleanup and optimizations From: Davidlohr Bueso Date: Wed, 06 Nov 2013 13:41:59 -0800 In-Reply-To: <1383773816.11046.352.camel@schen9-DESK> References: <1383773816.11046.352.camel@schen9-DESK> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen Cc: Ingo Molnar , Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On Wed, 2013-11-06 at 13:36 -0800, Tim Chen wrote: > In this patch series, we separated out the MCS lock code which was > previously embedded in the mutex.c. This allows for easier reuse of > MCS lock in other places like rwsem and qrwlock. We also did some micro > optimizations and barrier cleanup. > > This patches were previously part of the rwsem optimization patch series > but now we spearate them out. > > Tim Chen > > v3: > 1. modified memory barriers to support non x86 architectures that have > weak memory ordering. > > v2: > 1. change export mcs_spin_lock as a GPL export symbol > 2. corrected mcs_spin_lock to references > > > Jason Low (2): > MCS Lock: optimizations and extra comments > MCS Lock: Barrier corrections > > > Jason Low (2): > MCS Lock: optimizations and extra comments > MCS Lock: Barrier corrections > > Tim Chen (1): > MCS Lock: Restructure the MCS lock defines and locking code into its > own file > > Waiman Long (2): > MCS Lock: Make mcs_spinlock.h includable in other files > MCS Lock: Allow architecture specific memory barrier in lock/unlock > > arch/x86/include/asm/barrier.h | 6 +++ > include/linux/mcs_spinlock.h | 25 ++++++++++ > include/linux/mutex.h | 5 +- > kernel/Makefile | 6 +- > kernel/mcs_spinlock.c | 96 ++++++++++++++++++++++++++++++++++++++++ > kernel/mutex.c | 60 +++---------------------- > 6 files changed, 140 insertions(+), 58 deletions(-) > create mode 100644 include/linux/mcs_spinlock.h > create mode 100644 kernel/mcs_spinlock.c Hmm I noticed that Peter's patchset to move locking mechanisms into a unique directory is now in -tip, ie: http://marc.info/?l=linux-kernel&m=138373682928585 So we'll have problems applying this patchset, it would probably be best to rebase on top. Thanks, Davidlohr -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by kanga.kvack.org (Postfix) with ESMTP id AF67A6B0119 for ; Wed, 6 Nov 2013 16:42:28 -0500 (EST) Received: by mail-pd0-f179.google.com with SMTP id y10so97847pdj.38 for ; Wed, 06 Nov 2013 13:42:28 -0800 (PST) Received: from psmtp.com ([74.125.245.172]) by mx.google.com with SMTP id j10si540256pac.25.2013.11.06.13.42.26 for ; Wed, 06 Nov 2013 13:42:26 -0800 (PST) Subject: Re: [PATCH v3 5/5] MCS Lock: Allow architecture specific memory barrier in lock/unlock From: Tim Chen In-Reply-To: <1383773836.11046.357.camel@schen9-DESK> References: <1383773836.11046.357.camel@schen9-DESK> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:42:21 -0800 Message-ID: <1383774141.11046.359.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On Wed, 2013-11-06 at 13:37 -0800, Tim Chen wrote: > This patch moves the decision of what kind of memory barriers to be > used in the MCS lock and unlock functions to the architecture specific > layer. It also moves the actual lock/unlock code to mcs_spinlock.c > file. > > A full memory barrier will be used if the following macros are not > defined: > 1) smp_mb__before_critical_section() > 2) smp_mb__after_critical_section() > > For the x86 architecture, only compiler barrier will be needed. > > Signed-off-by: Waiman Long > Signed-off-by: Tim Chen Should be Acked-by: Tim Chen > --- > arch/x86/include/asm/barrier.h | 6 +++ > include/linux/mcs_spinlock.h | 78 +------------------------------------- > kernel/mcs_spinlock.c | 81 ++++++++++++++++++++++++++++++++++++++- > 3 files changed, 86 insertions(+), 79 deletions(-) > > diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h > index c6cd358..6d0172c 100644 > --- a/arch/x86/include/asm/barrier.h > +++ b/arch/x86/include/asm/barrier.h > @@ -92,6 +92,12 @@ > #endif > #define smp_read_barrier_depends() read_barrier_depends() > #define set_mb(var, value) do { (void)xchg(&var, value); } while (0) > + > +#if !defined(CONFIG_X86_PPRO_FENCE) && !defined(CONFIG_X86_OOSTORE) > +# define smp_mb__before_critical_section() barrier() > +# define smp_mb__after_critical_section() barrier() > +#endif > + > #else > #define smp_mb() barrier() > #define smp_rmb() barrier() > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h > index f2c71e8..d54bb23 100644 > --- a/include/linux/mcs_spinlock.h > +++ b/include/linux/mcs_spinlock.h > @@ -12,19 +12,6 @@ > #ifndef __LINUX_MCS_SPINLOCK_H > #define __LINUX_MCS_SPINLOCK_H > > -/* > - * asm/processor.h may define arch_mutex_cpu_relax(). > - * If it is not defined, cpu_relax() will be used. > - */ > -#include > -#include > -#include > -#include > - > -#ifndef arch_mutex_cpu_relax > -# define arch_mutex_cpu_relax() cpu_relax() > -#endif > - > struct mcs_spinlock { > struct mcs_spinlock *next; > int locked; /* 1 if lock acquired */ > @@ -32,68 +19,7 @@ struct mcs_spinlock { > > extern > void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node); > - > -/* > - * In order to acquire the lock, the caller should declare a local node and > - * pass a reference of the node to this function in addition to the lock. > - * If the lock has already been acquired, then this will proceed to spin > - * on this node->locked until the previous lock holder sets the node->locked > - * in mcs_spin_unlock(). > - * > - * The _raw_mcs_spin_lock() function should not be called directly. Instead, > - * users should call mcs_spin_lock(). > - */ > -static inline > -void _raw_mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > -{ > - struct mcs_spinlock *prev; > - > - /* Init node */ > - node->locked = 0; > - node->next = NULL; > - > - /* xchg() provides a memory barrier */ > - prev = xchg(lock, node); > - if (likely(prev == NULL)) { > - /* Lock acquired */ > - return; > - } > - ACCESS_ONCE(prev->next) = node; > - /* Wait until the lock holder passes the lock down */ > - while (!ACCESS_ONCE(node->locked)) > - arch_mutex_cpu_relax(); > - > - /* Make sure subsequent operations happen after the lock is acquired */ > - smp_rmb(); > -} > - > -/* > - * Releases the lock. The caller should pass in the corresponding node that > - * was used to acquire the lock. > - */ > -static inline > -void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > -{ > - struct mcs_spinlock *next = ACCESS_ONCE(node->next); > - > - if (likely(!next)) { > - /* > - * cmpxchg() provides a memory barrier. > - * Release the lock by setting it to NULL > - */ > - if (likely(cmpxchg(lock, node, NULL) == node)) > - return; > - /* Wait until the next pointer is set */ > - while (!(next = ACCESS_ONCE(node->next))) > - arch_mutex_cpu_relax(); > - } else { > - /* > - * Make sure all operations within the critical section > - * happen before the lock is released. > - */ > - smp_wmb(); > - } > - ACCESS_ONCE(next->locked) = 1; > -} > +extern > +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node); > > #endif /* __LINUX_MCS_SPINLOCK_H */ > diff --git a/kernel/mcs_spinlock.c b/kernel/mcs_spinlock.c > index 3c55626..2dfd207 100644 > --- a/kernel/mcs_spinlock.c > +++ b/kernel/mcs_spinlock.c > @@ -7,15 +7,90 @@ > * It avoids expensive cache bouncings that common test-and-set spin-lock > * implementations incur. > */ > +/* > + * asm/processor.h may define arch_mutex_cpu_relax(). > + * If it is not defined, cpu_relax() will be used. > + */ > +#include > +#include > +#include > +#include > #include > #include > > +#ifndef arch_mutex_cpu_relax > +# define arch_mutex_cpu_relax() cpu_relax() > +#endif > + > /* > - * We don't inline mcs_spin_lock() so that perf can correctly account for the > - * time spent in this lock function. > + * Fall back to use full memory barrier if those macros are not defined > + * in a architecture specific header file. > + */ > +#ifndef smp_mb__before_critical_section > +#define smp_mb__before_critical_section() smp_mb() > +#endif > + > +#ifndef smp_mb__after_critical_section > +#define smp_mb__after_critical_section() smp_mb() > +#endif > + > + > +/* > + * In order to acquire the lock, the caller should declare a local node and > + * pass a reference of the node to this function in addition to the lock. > + * If the lock has already been acquired, then this will proceed to spin > + * on this node->locked until the previous lock holder sets the node->locked > + * in mcs_spin_unlock(). > */ > void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > { > - _raw_mcs_spin_lock(lock, node); > + struct mcs_spinlock *prev; > + > + /* Init node */ > + node->locked = 0; > + node->next = NULL; > + > + /* xchg() provides a memory barrier */ > + prev = xchg(lock, node); > + if (likely(prev == NULL)) { > + /* Lock acquired */ > + return; > + } > + ACCESS_ONCE(prev->next) = node; > + /* Wait until the lock holder passes the lock down */ > + while (!ACCESS_ONCE(node->locked)) > + arch_mutex_cpu_relax(); > + > + /* Make sure subsequent operations happen after the lock is acquired */ > + smp_mb__before_critical_section(); > } > EXPORT_SYMBOL_GPL(mcs_spin_lock); > + > +/* > + * Releases the lock. The caller should pass in the corresponding node that > + * was used to acquire the lock. > + */ > +void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > +{ > + struct mcs_spinlock *next = ACCESS_ONCE(node->next); > + > + if (likely(!next)) { > + /* > + * cmpxchg() provides a memory barrier. > + * Release the lock by setting it to NULL > + */ > + if (likely(cmpxchg(lock, node, NULL) == node)) > + return; > + /* Wait until the next pointer is set */ > + while (!(next = ACCESS_ONCE(node->next))) > + arch_mutex_cpu_relax(); > + } else { > + /* > + * Make sure all operations within the critical section > + * happen before the lock is released. > + */ > + smp_mb__after_critical_section(); > + } > + ACCESS_ONCE(next->locked) = 1; > +} > +EXPORT_SYMBOL_GPL(mcs_spin_unlock); -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by kanga.kvack.org (Postfix) with ESMTP id 676426B011B for ; Wed, 6 Nov 2013 16:43:41 -0500 (EST) Received: by mail-pa0-f46.google.com with SMTP id rd3so276198pab.33 for ; Wed, 06 Nov 2013 13:43:41 -0800 (PST) Received: from psmtp.com ([74.125.245.142]) by mx.google.com with SMTP id jp3si114736pbc.336.2013.11.06.13.43.38 for ; Wed, 06 Nov 2013 13:43:39 -0800 (PST) Message-ID: <527AB7CA.4020502@zytor.com> Date: Wed, 06 Nov 2013 13:42:34 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH v3 0/4] MCS Lock: MCS lock code cleanup and optimizations References: <1383773816.11046.352.camel@schen9-DESK> In-Reply-To: <1383773816.11046.352.camel@schen9-DESK> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen , Ingo Molnar , Andrew Morton , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On 11/06/2013 01:36 PM, Tim Chen wrote: > In this patch series, we separated out the MCS lock code which was > previously embedded in the mutex.c. This allows for easier reuse of > MCS lock in other places like rwsem and qrwlock. We also did some micro > optimizations and barrier cleanup. > > This patches were previously part of the rwsem optimization patch series > but now we spearate them out. > > Tim Chen Perhaps I'm missing something here, but what is MCS lock and what is the value? -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id C51326B011D for ; Wed, 6 Nov 2013 16:47:38 -0500 (EST) Received: by mail-pa0-f49.google.com with SMTP id lj1so277368pab.8 for ; Wed, 06 Nov 2013 13:47:38 -0800 (PST) Received: from psmtp.com ([74.125.245.176]) by mx.google.com with SMTP id j10si477131pac.344.2013.11.06.13.47.35 for ; Wed, 06 Nov 2013 13:47:36 -0800 (PST) Subject: Re: [PATCH v3 2/5] MCS Lock: optimizations and extra comments From: Tim Chen In-Reply-To: <1383773824.11046.354.camel@schen9-DESK> References: <1383773824.11046.354.camel@schen9-DESK> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 13:47:30 -0800 Message-ID: <1383774450.11046.361.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On Wed, 2013-11-06 at 13:37 -0800, Tim Chen wrote: > Remove unnecessary operation and make the cmpxchg(lock, node, NULL) == node > check in mcs_spin_unlock() likely() as it is likely that a race did not occur > most of the time. > > Also add in more comments describing how the local node is used in MCS locks. > > Reviewed-by: Tim Chen > Signed-off-by: Jason Low > Signed-off-by: Tim Chen Should be Acked-by: Tim Chen . My fat fingers accidentally added my signed off for all patches. Tim > --- > include/linux/mcs_spinlock.h | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h > index b5de3b0..96f14299 100644 > --- a/include/linux/mcs_spinlock.h > +++ b/include/linux/mcs_spinlock.h > @@ -18,6 +18,12 @@ struct mcs_spinlock { > }; > > /* > + * In order to acquire the lock, the caller should declare a local node and > + * pass a reference of the node to this function in addition to the lock. > + * If the lock has already been acquired, then this will proceed to spin > + * on this node->locked until the previous lock holder sets the node->locked > + * in mcs_spin_unlock(). > + * > * We don't inline mcs_spin_lock() so that perf can correctly account for the > * time spent in this lock function. > */ > @@ -33,7 +39,6 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > prev = xchg(lock, node); > if (likely(prev == NULL)) { > /* Lock acquired */ > - node->locked = 1; > return; > } > ACCESS_ONCE(prev->next) = node; > @@ -43,6 +48,10 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > arch_mutex_cpu_relax(); > } > > +/* > + * Releases the lock. The caller should pass in the corresponding node that > + * was used to acquire the lock. > + */ > static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node) > { > struct mcs_spinlock *next = ACCESS_ONCE(node->next); > @@ -51,7 +60,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod > /* > * Release the lock by setting it to NULL > */ > - if (cmpxchg(lock, node, NULL) == node) > + if (likely(cmpxchg(lock, node, NULL) == node)) > return; > /* Wait until the next pointer is set */ > while (!(next = ACCESS_ONCE(node->next))) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by kanga.kvack.org (Postfix) with ESMTP id 2ADE96B011F for ; Wed, 6 Nov 2013 16:59:19 -0500 (EST) Received: by mail-pd0-f181.google.com with SMTP id x10so118377pdj.26 for ; Wed, 06 Nov 2013 13:59:18 -0800 (PST) Received: from psmtp.com ([74.125.245.176]) by mx.google.com with SMTP id ar5si209434pbd.32.2013.11.06.13.59.16 for ; Wed, 06 Nov 2013 13:59:17 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id k4so2745539qaq.0 for ; Wed, 06 Nov 2013 13:59:15 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <527AB7CA.4020502@zytor.com> References: <1383773816.11046.352.camel@schen9-DESK> <527AB7CA.4020502@zytor.com> Date: Wed, 6 Nov 2013 13:59:14 -0800 Message-ID: Subject: Re: [PATCH v3 0/4] MCS Lock: MCS lock code cleanup and optimizations From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Tim Chen , Ingo Molnar , Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On Wed, Nov 6, 2013 at 1:42 PM, H. Peter Anvin wrote: > Perhaps I'm missing something here, but what is MCS lock and what is the > value? Its a kind of queued lock where each waiter spins on a a separate memory word, instead of having them all spin on the lock's memory word. This helps with scalability when many waiters queue on the same lock. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by kanga.kvack.org (Postfix) with ESMTP id 560C66B0129 for ; Wed, 6 Nov 2013 18:55:43 -0500 (EST) Received: by mail-pb0-f49.google.com with SMTP id um15so237983pbc.8 for ; Wed, 06 Nov 2013 15:55:42 -0800 (PST) Received: from psmtp.com ([74.125.245.115]) by mx.google.com with SMTP id je1si427073pbb.210.2013.11.06.15.55.40 for ; Wed, 06 Nov 2013 15:55:41 -0800 (PST) Subject: Re: [PATCH v3 0/4] MCS Lock: MCS lock code cleanup and optimizations From: Tim Chen In-Reply-To: <1383774119.13330.2.camel@buesod1.americas.hpqcorp.net> References: <1383773816.11046.352.camel@schen9-DESK> <1383774119.13330.2.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Nov 2013 15:55:14 -0800 Message-ID: <1383782114.11046.362.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: Ingo Molnar , Andrew Morton , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm , linux-arch@vger.kernel.org, Linus Torvalds , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , "Paul E.McKenney" , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , Will Deacon , "Figo.zhang" On Wed, 2013-11-06 at 13:41 -0800, Davidlohr Bueso wrote: > On Wed, 2013-11-06 at 13:36 -0800, Tim Chen wrote: > > In this patch series, we separated out the MCS lock code which was > > previously embedded in the mutex.c. This allows for easier reuse of > > MCS lock in other places like rwsem and qrwlock. We also did some micro > > optimizations and barrier cleanup. > > > > This patches were previously part of the rwsem optimization patch series > > but now we spearate them out. > > > > Tim Chen > > > > v3: > > 1. modified memory barriers to support non x86 architectures that have > > weak memory ordering. > > > > v2: > > 1. change export mcs_spin_lock as a GPL export symbol > > 2. corrected mcs_spin_lock to references > > > > > > Jason Low (2): > > MCS Lock: optimizations and extra comments > > MCS Lock: Barrier corrections > > > > > > Jason Low (2): > > MCS Lock: optimizations and extra comments > > MCS Lock: Barrier corrections > > > > Tim Chen (1): > > MCS Lock: Restructure the MCS lock defines and locking code into its > > own file > > > > Waiman Long (2): > > MCS Lock: Make mcs_spinlock.h includable in other files > > MCS Lock: Allow architecture specific memory barrier in lock/unlock > > > > arch/x86/include/asm/barrier.h | 6 +++ > > include/linux/mcs_spinlock.h | 25 ++++++++++ > > include/linux/mutex.h | 5 +- > > kernel/Makefile | 6 +- > > kernel/mcs_spinlock.c | 96 ++++++++++++++++++++++++++++++++++++++++ > > kernel/mutex.c | 60 +++---------------------- > > 6 files changed, 140 insertions(+), 58 deletions(-) > > create mode 100644 include/linux/mcs_spinlock.h > > create mode 100644 kernel/mcs_spinlock.c > > Hmm I noticed that Peter's patchset to move locking mechanisms into a > unique directory is now in -tip, ie: > > http://marc.info/?l=linux-kernel&m=138373682928585 > > So we'll have problems applying this patchset, it would probably be best > to rebase on top. Good point. Will update the patchset. Tim > > Thanks, > Davidlohr > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by kanga.kvack.org (Postfix) with ESMTP id F3BDA6B013B for ; Wed, 6 Nov 2013 20:39:56 -0500 (EST) Received: by mail-pb0-f54.google.com with SMTP id ro12so339938pbb.13 for ; Wed, 06 Nov 2013 17:39:56 -0800 (PST) Received: from psmtp.com ([74.125.245.124]) by mx.google.com with SMTP id j10si1073978pac.54.2013.11.06.17.39.53 for ; Wed, 06 Nov 2013 17:39:55 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id if17so214875vcb.41 for ; Wed, 06 Nov 2013 17:39:52 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1383773827.11046.355.camel@schen9-DESK> References: <1383773827.11046.355.camel@schen9-DESK> Date: Thu, 7 Nov 2013 10:39:52 +0900 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Linus Torvalds Content-Type: multipart/alternative; boundary=20cf3079b7fc92942704ea8c57ee Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen Cc: Arnd Bergmann , "Figo. zhang" , Aswin Chandramouleeswaran , Rik van Riel , Waiman Long , Raghavendra K T , "Paul E.McKenney" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Alex Shi , Andrea Arcangeli , Scott J Norton , linux-kernel@vger.kernel.org, Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso --20cf3079b7fc92942704ea8c57ee Content-Type: text/plain; charset=UTF-8 Sorry about the HTML crap, the internet connection is too slow for my normal email habits, so I'm using my phone. I think the barriers are still totally wrong for the locking functions. Adding an smp_rmb after waiting for the lock is pure BS. Writes in the locked region could percolate out of the locked region. The thing is, you cannot do the memory ordering for locks in any same generic way. Not using our current barrier system. On x86 (and many others) the smp_rmb will work fine, because writes are never moved earlier. But on other architectures you really need an acquire to get a lock efficiently. No separate barriers. An acquire needs to be on the instruction that does the lock. Same goes for unlock. On x86 any store is a fine unlock, but on other architectures you need a store with a release marker. So no amount of barriers will ever do this correctly. Sure, you can add full memory barriers and it will be "correct" but it will be unbearably slow, and add totally unnecessary serialization. So *correct* locking will require architecture support. Linus On Nov 7, 2013 6:37 AM, "Tim Chen" wrote: > This patch corrects the way memory barriers are used in the MCS lock > and removes ones that are not needed. Also add comments on all barriers. > > Reviewed-by: Tim Chen > Signed-off-by: Jason Low > Signed-off-by: Tim Chen > --- > include/linux/mcs_spinlock.h | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h > index 96f14299..93d445d 100644 > --- a/include/linux/mcs_spinlock.h > +++ b/include/linux/mcs_spinlock.h > @@ -36,16 +36,19 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct > mcs_spinlock *node) > node->locked = 0; > node->next = NULL; > > + /* xchg() provides a memory barrier */ > prev = xchg(lock, node); > if (likely(prev == NULL)) { > /* Lock acquired */ > return; > } > ACCESS_ONCE(prev->next) = node; > - smp_wmb(); > /* Wait until the lock holder passes the lock down */ > while (!ACCESS_ONCE(node->locked)) > arch_mutex_cpu_relax(); > + > + /* Make sure subsequent operations happen after the lock is > acquired */ > + smp_rmb(); > } > > /* > @@ -58,6 +61,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, > struct mcs_spinlock *nod > > if (likely(!next)) { > /* > + * cmpxchg() provides a memory barrier. > * Release the lock by setting it to NULL > */ > if (likely(cmpxchg(lock, node, NULL) == node)) > @@ -65,9 +69,14 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, > struct mcs_spinlock *nod > /* Wait until the next pointer is set */ > while (!(next = ACCESS_ONCE(node->next))) > arch_mutex_cpu_relax(); > + } else { > + /* > + * Make sure all operations within the critical section > + * happen before the lock is released. > + */ > + smp_wmb(); > } > ACCESS_ONCE(next->locked) = 1; > - smp_wmb(); > } > > #endif /* __LINUX_MCS_SPINLOCK_H */ > -- > 1.7.4.4 > > > > --20cf3079b7fc92942704ea8c57ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry about the HTML crap, the internet connection is too sl= ow for my normal email habits, so I'm using my phone.

I think the barriers are still totally wrong for the locking= functions.

Adding an smp_rmb after waiting for the lock is pure BS. Wri= tes in the locked region could percolate out of the locked region.

The thing is, you cannot do the memory ordering for locks in= any same generic way. Not using our current barrier system. On x86 (and ma= ny others) the smp_rmb will work fine, because writes are never moved earli= er. But on other architectures you really need an acquire to get a lock eff= iciently. No separate barriers. An acquire needs to be on the instruction t= hat does the lock.

Same goes for unlock. On x86 any store is a fine unlock, but= on other architectures you need a store with a release marker.

So no amount of barriers will ever do this correctly. Sure, = you can add full memory barriers and it will be "correct" but it = will be unbearably slow, and add totally unnecessary serialization. So *cor= rect* locking will require architecture support.

=C2=A0=C2=A0=C2=A0=C2=A0 Linus

On Nov 7, 2013 6:37 AM, "Tim Chen" <= ;tim.c.chen@linux.intel.com> wrote:
This patch corrects the way memory barriers are used in the MCS lock
and removes ones that are not needed. Also add comments on all barriers.
Reviewed-by: Tim Chen <
tim= .c.chen@linux.intel.com>
Signed-off-by: Jason Low <jason.low= 2@hp.com>
Signed-off-by: Tim Chen <t= im.c.chen@linux.intel.com>
---
=C2=A0include/linux/mcs_spinlock.h | =C2=A0 13 +++++++++++--
=C2=A01 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/mcs_spinlock.h b/include/linux/mcs_spinlock.h index 96f14299..93d445d 100644
--- a/include/linux/mcs_spinlock.h
+++ b/include/linux/mcs_spinlock.h
@@ -36,16 +36,19 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct m= cs_spinlock *node)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 node->locked =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 node->next =C2=A0 =3D NULL;

+ =C2=A0 =C2=A0 =C2=A0 /* xchg() provides a memory barrier */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prev =3D xchg(lock, node);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (likely(prev =3D=3D NULL)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Lock acquired */=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ACCESS_ONCE(prev->next) =3D node;
- =C2=A0 =C2=A0 =C2=A0 smp_wmb();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Wait until the lock holder passes the lock d= own */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 while (!ACCESS_ONCE(node->locked))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 arch_mutex_cpu_rela= x();
+
+ =C2=A0 =C2=A0 =C2=A0 /* Make sure subsequent operations happen after the = lock is acquired */
+ =C2=A0 =C2=A0 =C2=A0 smp_rmb();
=C2=A0}

=C2=A0/*
@@ -58,6 +61,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, s= truct mcs_spinlock *nod

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (likely(!next)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* cmpxchg() provid= es a memory barrier.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Release the= lock by setting it to NULL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (likely(cmpxchg(= lock, node, NULL) =3D=3D node))
@@ -65,9 +69,14 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, = struct mcs_spinlock *nod
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Wait until the n= ext pointer is set */
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while (!(next =3D A= CCESS_ONCE(node->next)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 arch_mutex_cpu_relax();
+ =C2=A0 =C2=A0 =C2=A0 } else {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /*
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Make sure all op= erations within the critical section
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* happen before th= e lock is released.
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 smp_wmb();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ACCESS_ONCE(next->locked) =3D 1;
- =C2=A0 =C2=A0 =C2=A0 smp_wmb();
=C2=A0}

=C2=A0#endif /* __LINUX_MCS_SPINLOCK_H */
--
1.7.4.4



--20cf3079b7fc92942704ea8c57ee-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by kanga.kvack.org (Postfix) with ESMTP id 72F3A6B013E for ; Wed, 6 Nov 2013 23:30:34 -0500 (EST) Received: by mail-pd0-f170.google.com with SMTP id v10so24557pde.1 for ; Wed, 06 Nov 2013 20:30:34 -0800 (PST) Received: from psmtp.com ([74.125.245.173]) by mx.google.com with SMTP id yk3si1543669pac.12.2013.11.06.20.30.15 for ; Wed, 06 Nov 2013 20:30:31 -0800 (PST) Message-ID: <527B1742.60400@hp.com> Date: Wed, 06 Nov 2013 23:29:54 -0500 From: Waiman Long MIME-Version: 1.0 Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections References: <1383773827.11046.355.camel@schen9-DESK> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010800000509090703040100" Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Tim Chen , Arnd Bergmann , "Figo. zhang" , Aswin Chandramouleeswaran , Rik van Riel , Raghavendra K T , "Paul E.McKenney" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Alex Shi , Andrea Arcangeli , Scott J Norton , linux-kernel@vger.kernel.org, Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso This is a multi-part message in MIME format. --------------010800000509090703040100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/06/2013 08:39 PM, Linus Torvalds wrote: > > Sorry about the HTML crap, the internet connection is too slow for my > normal email habits, so I'm using my phone. > > I think the barriers are still totally wrong for the locking functions. > > Adding an smp_rmb after waiting for the lock is pure BS. Writes in the > locked region could percolate out of the locked region. > > The thing is, you cannot do the memory ordering for locks in any same > generic way. Not using our current barrier system. On x86 (and many > others) the smp_rmb will work fine, because writes are never moved > earlier. But on other architectures you really need an acquire to get > a lock efficiently. No separate barriers. An acquire needs to be on > the instruction that does the lock. > > Same goes for unlock. On x86 any store is a fine unlock, but on other > architectures you need a store with a release marker. > > So no amount of barriers will ever do this correctly. Sure, you can > add full memory barriers and it will be "correct" but it will be > unbearably slow, and add totally unnecessary serialization. So > *correct* locking will require architecture support. > > Yes, we realized that we can't do it in a generic way without introducing unwanted overhead. So I had sent out another patch to do it in an architecture specific way to enable each architecture to choose their memory barrier. It was at the end of the v3 and v4 patch series. -Longman --------------010800000509090703040100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/06/2013 08:39 PM, Linus Torvalds wrote:

Sorry about the HTML crap, the internet connection is too slow for my normal email habits, so I'm using my phone.

I think the barriers are still totally wrong for the locking functions.

Adding an smp_rmb after waiting for the lock is pure BS. Writes in the locked region could percolate out of the locked region.

The thing is, you cannot do the memory ordering for locks in any same generic way. Not using our current barrier system. On x86 (and many others) the smp_rmb will work fine, because writes are never moved earlier. But on other architectures you really need an acquire to get a lock efficiently. No separate barriers. An acquire needs to be on the instruction that does the lock.

Same goes for unlock. On x86 any store is a fine unlock, but on other architectures you need a store with a release marker.

So no amount of barriers will ever do this correctly. Sure, you can add full memory barriers and it will be "correct" but it will be unbearably slow, and add totally unnecessary serialization. So *correct* locking will require architecture support.

A A A A


Yes, we realized that we can't do it in a generic way without introducing unwanted overhead. So I had sent out another patch to do it in an architecture specific way to enable each architecture to choose their memory barrier. It was at the end of the v3 and v4 patch series.

-Longman
--------------010800000509090703040100-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by kanga.kvack.org (Postfix) with ESMTP id B0B386B0143 for ; Thu, 7 Nov 2013 03:13:13 -0500 (EST) Received: by mail-pd0-f179.google.com with SMTP id y10so245176pdj.24 for ; Thu, 07 Nov 2013 00:13:13 -0800 (PST) Received: from psmtp.com ([74.125.245.103]) by mx.google.com with SMTP id tu7si2128286pab.191.2013.11.07.00.13.11 for ; Thu, 07 Nov 2013 00:13:12 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id b47so99591eek.16 for ; Thu, 07 Nov 2013 00:13:09 -0800 (PST) Date: Thu, 7 Nov 2013 09:13:06 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections Message-ID: <20131107081306.GA32438@gmail.com> References: <1383773827.11046.355.camel@schen9-DESK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Tim Chen , Arnd Bergmann , "Figo. zhang" , Aswin Chandramouleeswaran , Rik van Riel , Waiman Long , Raghavendra K T , "Paul E.McKenney" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Alex Shi , Andrea Arcangeli , Scott J Norton , linux-kernel@vger.kernel.org, Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso Linus, A more general maintenance question: do you agree with the whole idea to factor out the MCS logic from mutex.c to make it reusable? This optimization patch makes me think it's a useful thing to do: [PATCH v3 2/5] MCS Lock: optimizations and extra comments as that kicks back optimizations to the mutex code as well. It also brought some spotlight on mutex code that it would not have gotten otherwise. That advantage is also its disadvantage: additional coupling between rwsem and mutex logic internals. But not like it's overly hard to undo this change, so I'm in general in favor of this direction ... So unless you object to this direction, I planned to apply this preparatory series to the locking tree once we are all happy with all the fine details. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by kanga.kvack.org (Postfix) with ESMTP id C3FC06B0146 for ; Thu, 7 Nov 2013 03:22:27 -0500 (EST) Received: by mail-pd0-f175.google.com with SMTP id g10so257687pdj.34 for ; Thu, 07 Nov 2013 00:22:27 -0800 (PST) Received: from psmtp.com ([74.125.245.134]) by mx.google.com with SMTP id hi3si1829746pbb.3.2013.11.07.00.22.25 for ; Thu, 07 Nov 2013 00:22:26 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hu8so134312vcb.28 for ; Thu, 07 Nov 2013 00:22:24 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131107081306.GA32438@gmail.com> References: <1383773827.11046.355.camel@schen9-DESK> <20131107081306.GA32438@gmail.com> Date: Thu, 7 Nov 2013 17:22:24 +0900 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Linus Torvalds Content-Type: multipart/alternative; boundary=047d7b67747221cbd004ea91f737 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , "Paul E.McKenney" , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso --047d7b67747221cbd004ea91f737 Content-Type: text/plain; charset=UTF-8 I don't necessarily mind the factoring out, I just think it needs to be really solid and clear if - and *before* - we do this. We do *not* want to factor out some half-arsed implementation and then have later patches to fix up the crud. Nor when multiple different locks then use that common code. So I think it needs to be *clearly* great code before it gets factored out. Because before it is great code, it should not be shared with anything else. Linus On Nov 7, 2013 5:13 PM, "Ingo Molnar" wrote: > > Linus, > > A more general maintenance question: do you agree with the whole idea to > factor out the MCS logic from mutex.c to make it reusable? > > This optimization patch makes me think it's a useful thing to do: > > [PATCH v3 2/5] MCS Lock: optimizations and extra comments > > as that kicks back optimizations to the mutex code as well. It also > brought some spotlight on mutex code that it would not have gotten > otherwise. > > That advantage is also its disadvantage: additional coupling between rwsem > and mutex logic internals. But not like it's overly hard to undo this > change, so I'm in general in favor of this direction ... > > So unless you object to this direction, I planned to apply this > preparatory series to the locking tree once we are all happy with all the > fine details. > > Thanks, > > Ingo > --047d7b67747221cbd004ea91f737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I don't necessarily mind the factoring out, I just think= it needs to be really solid and clear if - and *before* - we do this. We d= o *not* want to factor out some half-arsed implementation and then have lat= er patches to fix up the crud. Nor when multiple different locks then use t= hat common code.

So I think it needs to be *clearly* great code before it get= s factored out. Because before it is great code, it should not be shared wi= th anything else.

=C2=A0=C2=A0=C2=A0=C2=A0 Linus

On Nov 7, 2013 5:13 PM, "Ingo Molnar" = <mingo@kernel.org> wrote:

Linus,

A more general maintenance question: do you agree with the whole idea to factor out the MCS logic from mutex.c to make it reusable?

This optimization patch makes me think it's a useful thing to do:

=C2=A0 [PATCH v3 2/5] MCS Lock: optimizations and extra comments

as that kicks back optimizations to the mutex code as well. It also
brought some spotlight on mutex code that it would not have gotten
otherwise.

That advantage is also its disadvantage: additional coupling between rwsem<= br> and mutex logic internals. But not like it's overly hard to undo this change, so I'm in general in favor of this direction ...

So unless you object to this direction, I planned to apply this
preparatory series to the locking tree once we are all happy with all the fine details.

Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Ingo
--047d7b67747221cbd004ea91f737-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by kanga.kvack.org (Postfix) with ESMTP id E309F6B0148 for ; Thu, 7 Nov 2013 03:25:50 -0500 (EST) Received: by mail-pa0-f47.google.com with SMTP id lf10so264581pab.34 for ; Thu, 07 Nov 2013 00:25:50 -0800 (PST) Received: from psmtp.com ([74.125.245.141]) by mx.google.com with SMTP id zt6si2193567pac.61.2013.11.07.00.25.48 for ; Thu, 07 Nov 2013 00:25:49 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id b11so116146eae.39 for ; Thu, 07 Nov 2013 00:25:46 -0800 (PST) Date: Thu, 7 Nov 2013 09:25:41 +0100 From: Ingo Molnar Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections Message-ID: <20131107082541.GA32542@gmail.com> References: <1383773827.11046.355.camel@schen9-DESK> <20131107081306.GA32438@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , "Paul E.McKenney" , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Michel Lespinasse , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso * Linus Torvalds wrote: > I don't necessarily mind the factoring out, I just think it needs to be > really solid and clear if - and *before* - we do this. [...] Okay, agreed. > [...] We do *not* want to factor out some half-arsed implementation and > then have later patches to fix up the crud. Nor when multiple different > locks then use that common code. > > So I think it needs to be *clearly* great code before it gets factored > out. Because before it is great code, it should not be shared with > anything else. Ok, we'll go through it with a fine comb and I won't rush merging it. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by kanga.kvack.org (Postfix) with ESMTP id 00AAB6B014E for ; Thu, 7 Nov 2013 04:55:41 -0500 (EST) Received: by mail-pb0-f51.google.com with SMTP id xa7so366262pbc.10 for ; Thu, 07 Nov 2013 01:55:41 -0800 (PST) Received: from psmtp.com ([74.125.245.168]) by mx.google.com with SMTP id pz2si2444496pac.86.2013.11.07.01.55.39 for ; Thu, 07 Nov 2013 01:55:40 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id w8so239772qac.20 for ; Thu, 07 Nov 2013 01:55:38 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1383773827.11046.355.camel@schen9-DESK> Date: Thu, 7 Nov 2013 01:55:37 -0800 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Tim Chen , Arnd Bergmann , "Figo. zhang" , Aswin Chandramouleeswaran , Rik van Riel , Waiman Long , Raghavendra K T , "Paul E.McKenney" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Alex Shi , Andrea Arcangeli , Scott J Norton , linux-kernel@vger.kernel.org, Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Wed, Nov 6, 2013 at 5:39 PM, Linus Torvalds wrote: > Sorry about the HTML crap, the internet connection is too slow for my normal > email habits, so I'm using my phone. > > I think the barriers are still totally wrong for the locking functions. > > Adding an smp_rmb after waiting for the lock is pure BS. Writes in the > locked region could percolate out of the locked region. > > The thing is, you cannot do the memory ordering for locks in any same > generic way. Not using our current barrier system. On x86 (and many others) > the smp_rmb will work fine, because writes are never moved earlier. But on > other architectures you really need an acquire to get a lock efficiently. No > separate barriers. An acquire needs to be on the instruction that does the > lock. > > Same goes for unlock. On x86 any store is a fine unlock, but on other > architectures you need a store with a release marker. > > So no amount of barriers will ever do this correctly. Sure, you can add full > memory barriers and it will be "correct" but it will be unbearably slow, and > add totally unnecessary serialization. So *correct* locking will require > architecture support. Rather than writing arch-specific locking code, would you agree to introduce acquire and release memory operations ? The semantics of an acquire memory operation would be: the specified memory operation occurs, and any reads or writes after that operation are guaranteed not to be reordered before it (useful to implement lock acquisitions). The semantics of a release memory operation would be: the specified memory operation occurs, and any reads or writes before that operation are guaranteed not to be reordered after it (useful to implement lock releases). Now each arch would still need to define several acquire and release operations, but this is a quite useful model to build generic code on. For example, the fast path for the x86 spinlock implementation could be expressed generically as an acquire fetch-and-add (for __ticket_spin_lock) and a release add (for __ticket_spin_unlock). Would you think this is a useful direction to move to ? Thanks, -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by kanga.kvack.org (Postfix) with ESMTP id 80EBF6B0152 for ; Thu, 7 Nov 2013 07:06:33 -0500 (EST) Received: by mail-pa0-f45.google.com with SMTP id kp14so517766pab.32 for ; Thu, 07 Nov 2013 04:06:33 -0800 (PST) Received: from psmtp.com ([74.125.245.156]) by mx.google.com with SMTP id ru9si2419278pbc.198.2013.11.07.04.06.31 for ; Thu, 07 Nov 2013 04:06:32 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so299878veb.13 for ; Thu, 07 Nov 2013 04:06:29 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1383773827.11046.355.camel@schen9-DESK> Date: Thu, 7 Nov 2013 21:06:29 +0900 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Linus Torvalds Content-Type: multipart/alternative; boundary=089e0115f6828bdaee04ea95184d Sender: owner-linux-mm@kvack.org List-ID: To: Michel Lespinasse Cc: Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , "Paul E.McKenney" , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso --089e0115f6828bdaee04ea95184d Content-Type: text/plain; charset=UTF-8 On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote: > > Rather than writing arch-specific locking code, would you agree to > introduce acquire and release memory operations ? Yes, that's probably the right thing to do. What ops do we need? Store with release, cmpxchg and load with acquire? Anything else? Linus --089e0115f6828bdaee04ea95184d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Nov 7, 2013 6:55 PM, "Michel Lespinasse" <walken@google.com> wrote:
>
> Rather than writing arch-specific locking code, would you agree to
> introduce acquire and release memory operations ?

Yes, that's probably the right thing to do. What ops do = we need? Store with release, cmpxchg and load with acquire? Anything else?<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Linus

--089e0115f6828bdaee04ea95184d-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by kanga.kvack.org (Postfix) with ESMTP id 4D4CC6B0156 for ; Thu, 7 Nov 2013 07:50:27 -0500 (EST) Received: by mail-pa0-f48.google.com with SMTP id kq14so555111pab.7 for ; Thu, 07 Nov 2013 04:50:26 -0800 (PST) Received: from psmtp.com ([74.125.245.116]) by mx.google.com with SMTP id cx4si2558268pbc.119.2013.11.07.04.50.25 for ; Thu, 07 Nov 2013 04:50:26 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id v1so335491qcw.19 for ; Thu, 07 Nov 2013 04:50:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1383773827.11046.355.camel@schen9-DESK> Date: Thu, 7 Nov 2013 04:50:23 -0800 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , "Paul E.McKenney" , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds wrote: > > On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote: >> >> Rather than writing arch-specific locking code, would you agree to >> introduce acquire and release memory operations ? > > Yes, that's probably the right thing to do. What ops do we need? Store with > release, cmpxchg and load with acquire? Anything else? Depends on what lock types we want to implement on top; for MCS we would need: - xchg acquire (common case) and load acquire (for spinning on our locker's wait word) - cmpxchg release (when there is no next locker) and store release (when writing to the next locker's wait word) One downside of the proposal is that using a load acquire for spinning puts the memory barrier within the spin loop. So this model is very intuitive and does not add unnecessary barriers on x86, but it my place the barriers in a suboptimal place for architectures that need them. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by kanga.kvack.org (Postfix) with ESMTP id 718F66B0160 for ; Thu, 7 Nov 2013 09:32:52 -0500 (EST) Received: by mail-pa0-f53.google.com with SMTP id kx10so682301pab.40 for ; Thu, 07 Nov 2013 06:32:52 -0800 (PST) Received: from psmtp.com ([74.125.245.136]) by mx.google.com with SMTP id sd2si2817333pbb.289.2013.11.07.06.32.50 for ; Thu, 07 Nov 2013 06:32:51 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Nov 2013 09:32:48 -0500 Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id CFED36E807F for ; Thu, 7 Nov 2013 09:32:40 -0500 (EST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b01cxnp23033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA7EWfHi66715856 for ; Thu, 7 Nov 2013 14:32:41 GMT Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id rA7EYTVa013564 for ; Thu, 7 Nov 2013 07:34:31 -0700 Date: Thu, 7 Nov 2013 06:31:39 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections Message-ID: <20131107143139.GT18245@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1383773827.11046.355.camel@schen9-DESK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Michel Lespinasse Cc: Linus Torvalds , Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, Nov 07, 2013 at 04:50:23AM -0800, Michel Lespinasse wrote: > On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds > wrote: > > > > On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote: > >> > >> Rather than writing arch-specific locking code, would you agree to > >> introduce acquire and release memory operations ? > > > > Yes, that's probably the right thing to do. What ops do we need? Store with > > release, cmpxchg and load with acquire? Anything else? > > Depends on what lock types we want to implement on top; for MCS we would need: > - xchg acquire (common case) and load acquire (for spinning on our > locker's wait word) > - cmpxchg release (when there is no next locker) and store release > (when writing to the next locker's wait word) > > One downside of the proposal is that using a load acquire for spinning > puts the memory barrier within the spin loop. So this model is very > intuitive and does not add unnecessary barriers on x86, but it my > place the barriers in a suboptimal place for architectures that need > them. OK, I will bite... Why is a barrier in the spinloop suboptimal? Can't say that I have tried measuring it, but the barrier should not normally result in interconnect traffic. Given that the barrier is required anyway, it should not affect lock-acquisition latency. So what am I missing here? Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by kanga.kvack.org (Postfix) with ESMTP id 6409F6B0174 for ; Thu, 7 Nov 2013 14:59:53 -0500 (EST) Received: by mail-pb0-f45.google.com with SMTP id ma3so1074708pbc.18 for ; Thu, 07 Nov 2013 11:59:53 -0800 (PST) Received: from psmtp.com ([74.125.245.147]) by mx.google.com with SMTP id cj2si3738722pbc.57.2013.11.07.11.59.51 for ; Thu, 07 Nov 2013 11:59:52 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id i7so867116qcq.2 for ; Thu, 07 Nov 2013 11:59:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131107143139.GT18245@linux.vnet.ibm.com> References: <1383773827.11046.355.camel@schen9-DESK> <20131107143139.GT18245@linux.vnet.ibm.com> Date: Thu, 7 Nov 2013 11:59:49 -0800 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Paul McKenney Cc: Linus Torvalds , Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , LKML , Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, Nov 7, 2013 at 6:31 AM, Paul E. McKenney wrote: > On Thu, Nov 07, 2013 at 04:50:23AM -0800, Michel Lespinasse wrote: >> On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds >> wrote: >> > >> > On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote: >> >> >> >> Rather than writing arch-specific locking code, would you agree to >> >> introduce acquire and release memory operations ? >> > >> > Yes, that's probably the right thing to do. What ops do we need? Store with >> > release, cmpxchg and load with acquire? Anything else? >> >> Depends on what lock types we want to implement on top; for MCS we would need: >> - xchg acquire (common case) and load acquire (for spinning on our >> locker's wait word) >> - cmpxchg release (when there is no next locker) and store release >> (when writing to the next locker's wait word) >> >> One downside of the proposal is that using a load acquire for spinning >> puts the memory barrier within the spin loop. So this model is very >> intuitive and does not add unnecessary barriers on x86, but it my >> place the barriers in a suboptimal place for architectures that need >> them. > > OK, I will bite... Why is a barrier in the spinloop suboptimal? It's probably not a big deal - all I meant to say is that if you were manually placing barriers, you would probably put one after the loop instead. I don't deal much with architectures where such barriers are needed, so I don't know for sure if the difference means much. > Can't say that I have tried measuring it, but the barrier should not > normally result in interconnect traffic. Given that the barrier is > required anyway, it should not affect lock-acquisition latency. Agree > So what am I missing here? I think you read my second email as me trying to shoot down a proposal - I wasn't, as I really like the acquire/release model and find it easy to program with, which is why I'm proposing it in the first place. I just wanted to be upfront about all potential downsides, so we can consider them and see if they are significant - I don't think they are, but I'm not the best person to judge that as I mostly just deal with x86 stuff. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by kanga.kvack.org (Postfix) with ESMTP id 082376B017C for ; Thu, 7 Nov 2013 16:16:05 -0500 (EST) Received: by mail-pa0-f49.google.com with SMTP id lj1so1181450pab.8 for ; Thu, 07 Nov 2013 13:16:05 -0800 (PST) Received: from psmtp.com ([74.125.245.143]) by mx.google.com with SMTP id t6si4215749paa.337.2013.11.07.13.16.03 for ; Thu, 07 Nov 2013 13:16:04 -0800 (PST) Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Tim Chen In-Reply-To: References: <1383773827.11046.355.camel@schen9-DESK> <20131107143139.GT18245@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Nov 2013 13:15:51 -0800 Message-ID: <1383858951.11046.399.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michel Lespinasse Cc: Paul McKenney , Linus Torvalds , Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , LKML , Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, 2013-11-07 at 11:59 -0800, Michel Lespinasse wrote: > On Thu, Nov 7, 2013 at 6:31 AM, Paul E. McKenney > wrote: > > On Thu, Nov 07, 2013 at 04:50:23AM -0800, Michel Lespinasse wrote: > >> On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds > >> wrote: > >> > > >> > On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote: > >> >> > >> >> Rather than writing arch-specific locking code, would you agree to > >> >> introduce acquire and release memory operations ? > >> > > >> > Yes, that's probably the right thing to do. What ops do we need? Store with > >> > release, cmpxchg and load with acquire? Anything else? > >> > >> Depends on what lock types we want to implement on top; for MCS we would need: > >> - xchg acquire (common case) and load acquire (for spinning on our > >> locker's wait word) > >> - cmpxchg release (when there is no next locker) and store release > >> (when writing to the next locker's wait word) > >> > >> One downside of the proposal is that using a load acquire for spinning > >> puts the memory barrier within the spin loop. So this model is very > >> intuitive and does not add unnecessary barriers on x86, but it my > >> place the barriers in a suboptimal place for architectures that need > >> them. > > > > OK, I will bite... Why is a barrier in the spinloop suboptimal? > > It's probably not a big deal - all I meant to say is that if you were > manually placing barriers, you would probably put one after the loop > instead. I don't deal much with architectures where such barriers are > needed, so I don't know for sure if the difference means much. We could do a load acquire at the end of the spin loop in the lock function and not in the spin loop itself if cost of barrier within spin loop is a concern. Michel, are you planning to do an implementation of load-acquire/store-release functions of various architectures? Or is the approach of arch specific memory barrier for MCS an acceptable one before load-acquire and store-release are available? Are there any technical issues remaining with the patchset after including including Waiman's arch specific barrier? Tim > > > Can't say that I have tried measuring it, but the barrier should not > > normally result in interconnect traffic. Given that the barrier is > > required anyway, it should not affect lock-acquisition latency. > > Agree > > > So what am I missing here? > > I think you read my second email as me trying to shoot down a proposal > - I wasn't, as I really like the acquire/release model and find it > easy to program with, which is why I'm proposing it in the first > place. I just wanted to be upfront about all potential downsides, so > we can consider them and see if they are significant - I don't think > they are, but I'm not the best person to judge that as I mostly just > deal with x86 stuff. > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by kanga.kvack.org (Postfix) with ESMTP id 49FAC6B0125 for ; Thu, 7 Nov 2013 17:22:25 -0500 (EST) Received: by mail-pa0-f46.google.com with SMTP id rd3so1275816pab.19 for ; Thu, 07 Nov 2013 14:22:24 -0800 (PST) Received: from psmtp.com ([74.125.245.164]) by mx.google.com with SMTP id pl8si4018673pbb.344.2013.11.07.14.22.20 for ; Thu, 07 Nov 2013 14:22:21 -0800 (PST) Date: Thu, 7 Nov 2013 23:21:44 +0100 From: Peter Zijlstra Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections Message-ID: <20131107222144.GC19203@twins.programming.kicks-ass.net> References: <1383773827.11046.355.camel@schen9-DESK> <20131107143139.GT18245@linux.vnet.ibm.com> <1383858951.11046.399.camel@schen9-DESK> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1383858951.11046.399.camel@schen9-DESK> Sender: owner-linux-mm@kvack.org List-ID: To: Tim Chen Cc: Michel Lespinasse , Paul McKenney , Linus Torvalds , Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , George Spelvin , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , LKML , Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, Nov 07, 2013 at 01:15:51PM -0800, Tim Chen wrote: > Michel, are you planning to do an implementation of > load-acquire/store-release functions of various architectures? A little something like this: http://marc.info/?l=linux-arch&m=138386254111507 It so happens we were working on that the past week or so due to another issue ;-) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by kanga.kvack.org (Postfix) with ESMTP id 6752C6B0184 for ; Thu, 7 Nov 2013 17:43:54 -0500 (EST) Received: by mail-pd0-f179.google.com with SMTP id y10so1243837pdj.38 for ; Thu, 07 Nov 2013 14:43:54 -0800 (PST) Received: from psmtp.com ([74.125.245.118]) by mx.google.com with SMTP id gw3si4465146pac.172.2013.11.07.14.43.51 for ; Thu, 07 Nov 2013 14:43:52 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id cy11so1173068qeb.40 for ; Thu, 07 Nov 2013 14:43:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131107222144.GC19203@twins.programming.kicks-ass.net> References: <1383773827.11046.355.camel@schen9-DESK> <20131107143139.GT18245@linux.vnet.ibm.com> <1383858951.11046.399.camel@schen9-DESK> <20131107222144.GC19203@twins.programming.kicks-ass.net> Date: Thu, 7 Nov 2013 14:43:49 -0800 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Tim Chen , Paul McKenney , Linus Torvalds , Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , George Spelvin , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , LKML , Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, Nov 7, 2013 at 2:21 PM, Peter Zijlstra wrote: > On Thu, Nov 07, 2013 at 01:15:51PM -0800, Tim Chen wrote: >> Michel, are you planning to do an implementation of >> load-acquire/store-release functions of various architectures? > > A little something like this: > http://marc.info/?l=linux-arch&m=138386254111507 > > It so happens we were working on that the past week or so due to another > issue ;-) Haha, awesome, I wasn't aware of this effort. Tim: my approach would be to provide the acquire/release operations in arch-specific include files, and have a default implementation using barriers for arches who don't provide these new ops. That way you make it work on all arches at once (using the default implementation) and make it fast on any arch that cares. >> Or is the approach of arch specific memory barrier for MCS >> an acceptable one before load-acquire and store-release >> are available? Are there any technical issues remaining with >> the patchset after including including Waiman's arch specific barrier? I don't want to stand in the way of Waiman's change, and I had actually taken the same approach with arch-specific barriers when proposing some queue spinlocks in the past; however I do feel that this comes back regularly enough that having acquire/release primitives available would help, hence my proposal. That said, earlier in the thread Linus said we should probably get all our ducks in a row before going forward with this, so... -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by kanga.kvack.org (Postfix) with ESMTP id A13246B0186 for ; Thu, 7 Nov 2013 20:16:40 -0500 (EST) Received: by mail-pb0-f48.google.com with SMTP id mc8so1388606pbc.7 for ; Thu, 07 Nov 2013 17:16:40 -0800 (PST) Received: from psmtp.com ([74.125.245.176]) by mx.google.com with SMTP id pz2si4823204pac.173.2013.11.07.17.16.38 for ; Thu, 07 Nov 2013 17:16:39 -0800 (PST) Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Tim Chen In-Reply-To: References: <1383773827.11046.355.camel@schen9-DESK> <20131107143139.GT18245@linux.vnet.ibm.com> <1383858951.11046.399.camel@schen9-DESK> <20131107222144.GC19203@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Nov 2013 17:16:32 -0800 Message-ID: <1383873392.11046.402.camel@schen9-DESK> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michel Lespinasse Cc: Peter Zijlstra , Paul McKenney , Linus Torvalds , Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , George Spelvin , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , LKML , Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, 2013-11-07 at 14:43 -0800, Michel Lespinasse wrote: > On Thu, Nov 7, 2013 at 2:21 PM, Peter Zijlstra wrote: > > On Thu, Nov 07, 2013 at 01:15:51PM -0800, Tim Chen wrote: > >> Michel, are you planning to do an implementation of > >> load-acquire/store-release functions of various architectures? > > > > A little something like this: > > http://marc.info/?l=linux-arch&m=138386254111507 > > > > It so happens we were working on that the past week or so due to another > > issue ;-) > > Haha, awesome, I wasn't aware of this effort. > > Tim: my approach would be to provide the acquire/release operations in > arch-specific include files, and have a default implementation using > barriers for arches who don't provide these new ops. That way you make > it work on all arches at once (using the default implementation) and > make it fast on any arch that cares. > > >> Or is the approach of arch specific memory barrier for MCS > >> an acceptable one before load-acquire and store-release > >> are available? Are there any technical issues remaining with > >> the patchset after including including Waiman's arch specific barrier? > > I don't want to stand in the way of Waiman's change, and I had > actually taken the same approach with arch-specific barriers when > proposing some queue spinlocks in the past; however I do feel that > this comes back regularly enough that having acquire/release > primitives available would help, hence my proposal. > > That said, earlier in the thread Linus said we should probably get all > our ducks in a row before going forward with this, so... > With the load_acquire and store_release implemented, it should be pretty straightforward to implement MCS with them. I'll respin the patch series with these primitives. Thanks. Tim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org