Re: [PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count
On 04/16/2013 06:05 AM, Will Deacon wrote: On Mon, Apr 15, 2013 at 03:37:59PM +0100, Waiman Long wrote: If it is confirmed that all the supported architectures can allow a negative mutex count without incorrect behavior, we can then back out the architecture specific change and allow the mutex count to go to any negative number. That should further reduce contention for non-x86 architecture. If this is not the case, this patch should be dropped. A good starting point might be to look at the asm-generic mutex implementations, which clears up the majority of architectures. A cursory glance at mutex-dec.h suggests that it's OK to me... I think the generic version is fine with negative mutex count. However, it is the architecture specific versions (we have 22 of them as of 3.8) that I am worry about. I just don't have enough know-how and test machines to verify that. Regards, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count
On Mon, Apr 15, 2013 at 03:37:59PM +0100, Waiman Long wrote: > If it is confirmed that all the supported architectures can allow a > negative mutex count without incorrect behavior, we can then back > out the architecture specific change and allow the mutex count to > go to any negative number. That should further reduce contention for > non-x86 architecture. > > If this is not the case, this patch should be dropped. A good starting point might be to look at the asm-generic mutex implementations, which clears up the majority of architectures. A cursory glance at mutex-dec.h suggests that it's OK to me... Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count
On Mon, Apr 15, 2013 at 03:37:59PM +0100, Waiman Long wrote: If it is confirmed that all the supported architectures can allow a negative mutex count without incorrect behavior, we can then back out the architecture specific change and allow the mutex count to go to any negative number. That should further reduce contention for non-x86 architecture. If this is not the case, this patch should be dropped. A good starting point might be to look at the asm-generic mutex implementations, which clears up the majority of architectures. A cursory glance at mutex-dec.h suggests that it's OK to me... Will -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count
On 04/16/2013 06:05 AM, Will Deacon wrote: On Mon, Apr 15, 2013 at 03:37:59PM +0100, Waiman Long wrote: If it is confirmed that all the supported architectures can allow a negative mutex count without incorrect behavior, we can then back out the architecture specific change and allow the mutex count to go to any negative number. That should further reduce contention for non-x86 architecture. If this is not the case, this patch should be dropped. A good starting point might be to look at the asm-generic mutex implementations, which clears up the majority of architectures. A cursory glance at mutex-dec.h suggests that it's OK to me... I think the generic version is fine with negative mutex count. However, it is the architecture specific versions (we have 22 of them as of 3.8) that I am worry about. I just don't have enough know-how and test machines to verify that. Regards, Longman -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count
If it is confirmed that all the supported architectures can allow a negative mutex count without incorrect behavior, we can then back out the architecture specific change and allow the mutex count to go to any negative number. That should further reduce contention for non-x86 architecture. If this is not the case, this patch should be dropped. Signed-off-by: Waiman Long --- arch/x86/include/asm/mutex.h | 10 -- kernel/mutex.c |9 ++--- 2 files changed, 2 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/mutex.h b/arch/x86/include/asm/mutex.h index bc2a0b0..7d3a482 100644 --- a/arch/x86/include/asm/mutex.h +++ b/arch/x86/include/asm/mutex.h @@ -3,13 +3,3 @@ #else # include #endif - -#ifndef__ASM_MUTEX_H -#define__ASM_MUTEX_H -/* - * For the x86 architecture, it allows any negative number (besides -1) in - * the mutex count to indicate that some other threads are waiting on the - * mutex. - */ -#define __ARCH_ALLOW_ANY_NEGATIVE_MUTEX_COUNT 1 -#endif diff --git a/kernel/mutex.c b/kernel/mutex.c index e6a90de..5600bdf 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -38,15 +38,10 @@ #endif /* - * A mutex count of -1 indicates that waiters are sleeping waiting for the - * mutex. Some architectures can allow any negative number, not just -1, for - * this purpose. + * A negative mutex count indicates that waiters are sleeping waiting for the + * mutex. */ -#ifdef __ARCH_ALLOW_ANY_NEGATIVE_MUTEX_COUNT #defineMUTEX_SHOW_NO_WAITER(mutex) (atomic_read(&(mutex)->count) >= 0) -#else -#defineMUTEX_SHOW_NO_WAITER(mutex) (atomic_read(&(mutex)->count) != -1) -#endif void __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count
If it is confirmed that all the supported architectures can allow a negative mutex count without incorrect behavior, we can then back out the architecture specific change and allow the mutex count to go to any negative number. That should further reduce contention for non-x86 architecture. If this is not the case, this patch should be dropped. Signed-off-by: Waiman Long waiman.l...@hp.com --- arch/x86/include/asm/mutex.h | 10 -- kernel/mutex.c |9 ++--- 2 files changed, 2 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/mutex.h b/arch/x86/include/asm/mutex.h index bc2a0b0..7d3a482 100644 --- a/arch/x86/include/asm/mutex.h +++ b/arch/x86/include/asm/mutex.h @@ -3,13 +3,3 @@ #else # include asm/mutex_64.h #endif - -#ifndef__ASM_MUTEX_H -#define__ASM_MUTEX_H -/* - * For the x86 architecture, it allows any negative number (besides -1) in - * the mutex count to indicate that some other threads are waiting on the - * mutex. - */ -#define __ARCH_ALLOW_ANY_NEGATIVE_MUTEX_COUNT 1 -#endif diff --git a/kernel/mutex.c b/kernel/mutex.c index e6a90de..5600bdf 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -38,15 +38,10 @@ #endif /* - * A mutex count of -1 indicates that waiters are sleeping waiting for the - * mutex. Some architectures can allow any negative number, not just -1, for - * this purpose. + * A negative mutex count indicates that waiters are sleeping waiting for the + * mutex. */ -#ifdef __ARCH_ALLOW_ANY_NEGATIVE_MUTEX_COUNT #defineMUTEX_SHOW_NO_WAITER(mutex) (atomic_read((mutex)-count) = 0) -#else -#defineMUTEX_SHOW_NO_WAITER(mutex) (atomic_read((mutex)-count) != -1) -#endif void __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
