[PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count

2013-04-15 Thread Waiman Long
. 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

[PATCH 0/3 v2] mutex: Improve mutex performance by doing less atomic-ops better spinning

2013-04-15 Thread Waiman Long
desired. Waiman Long (3): mutex: Make more scalable by doing less atomic operations mutex: Queue mutex spinners with MCS lock to reduce cacheline contention mutex: back out architecture specific check for negative mutex count include/linux/mutex.h |3 ++ include/linux/sched.h |3

[PATCH v2 2/3] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

2013-04-15 Thread Waiman Long
locking and queuing overhead. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/mutex.h |3 ++ include/linux/sched.h |3 ++ kernel/mutex.c| 78 - kernel/sched/core.c | 24 +-- 4 files changed, 104

[PATCH v2 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-15 Thread Waiman Long
% | +4.2% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com Reviewed-by: Davidlohr Bueso davidlohr.bu...@hp.com --- arch/x86/include/asm/mutex.h | 10 ++ kernel/mutex.c | 19 --- 2 files

Re: [PATCH 0/3 v2] mutex: Improve mutex performance by doing less atomic-ops better spinning

2013-04-16 Thread Waiman Long
On 04/16/2013 05:12 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: [...] Patches 2 improves the mutex spinning process by reducing contention among the spinners when competing for the mutex. This is done by using a MCS lock to put the spinners in a queue so that only the first

Re: [PATCH v2 2/3] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

2013-04-16 Thread Waiman Long
On 04/16/2013 12:24 AM, Davidlohr Bueso wrote: On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote: [...] +typedef struct mspin_node { + struct mspin_node *next; + intlocked; /* 1 if lock acquired */ +} mspin_node_t; + +typedef mspin_node_t *mspin_lock_t; I

Re: [PATCH v2 optional 3/3] mutex: back out architecture specific check for negative mutex count

2013-04-16 Thread Waiman Long
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

Re: [PATCH v2 2/3] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

2013-04-16 Thread Waiman Long
On 04/16/2013 05:10 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3021,9 +3021,6 @@ static inline bool owner_running(struct mutex *lock, struct task_struct *owner) */ int mutex_spin_on_owner(struct mutex *lock,

[PATCH v3 2/5] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

2013-04-16 Thread Waiman Long
locking and queuing overhead. Signed-off-by: Waiman Long waiman.l...@hp.com Acked-by: Rik van Riel r...@redhat.com --- include/linux/mutex.h |3 ++ include/linux/sched.h |3 ++ kernel/mutex.c| 78 - kernel/sched/core.c | 24

[PATCH v3 5/5] mutex: Move mutex spinning code from sched/core.c back to mutex.c

2013-04-16 Thread Waiman Long
to kernel/mutex.c which is where they should belong. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/sched.h |4 --- kernel/mutex.c | 62 ++ kernel/sched/core.c | 63

[PATCH v3 0/5] mutex: Improve mutex performance by doing less atomic-ops better spinning

2013-04-16 Thread Waiman Long
SCHED_FEAT_OWNER_SPIN which was just an earlier hack for testing purpose. It also moves the mutex spinning code back to mutex.c. Waiman Long (5): mutex: Make more scalable by doing less atomic operations mutex: Queue mutex spinners with MCS lock to reduce cacheline contention mutex: back out

[PATCH v3 4/5] mutex: Remove new typedefs introduced in patch 2

2013-04-16 Thread Waiman Long
In response to the review comment from Davidlohr, this patch will remove the new typedefs introduced by patch 2. It also removes an unnecessary barrier() call. Signed-off-by: Waiman Long waiman.l...@hp.com --- kernel/mutex.c | 25 +++-- 1 files changed, 11 insertions(+), 14

[PATCH v3 optional 3/5] mutex: back out architecture specific check for negative mutex count

2013-04-16 Thread Waiman Long
. 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

[PATCH v3 1/5] mutex: Make more scalable by doing less atomic operations

2013-04-16 Thread Waiman Long
% | +4.2% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com Reviewed-by: Davidlohr Bueso davidlohr.bu...@hp.com Reviewed-by: Rik van Riel r...@redhat.com --- arch/x86/include/asm/mutex.h | 10 ++ kernel/mutex.c

[PATCH v4 0/4] mutex: Improve mutex performance by doing less atomic-ops better spinning

2013-04-17 Thread Waiman Long
workloads. Patch 4 is an optional one for backing out architecture specific check in patch 2, if so desired. Waiman Long (4): mutex: Move mutex spinning code from sched/core.c back to mutex.c mutex: Make more scalable by doing less atomic operations mutex: Queue mutex spinners with MCS lock

[PATCH v4 2/4] mutex: Make more scalable by doing less atomic operations

2013-04-17 Thread Waiman Long
% | +4.2% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com Reviewed-by: Davidlohr Bueso davidlohr.bu...@hp.com Reviewed-by: Rik van Riel r...@redhat.com --- arch/x86/include/asm/mutex.h | 10 ++ kernel/mutex.c

[PATCH v4 optional 4/4] mutex: back out architecture specific check for negative mutex count

2013-04-17 Thread Waiman Long
. 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

[PATCH v4 3/4] mutex: Queue mutex spinners with MCS lock to reduce cacheline contention

2013-04-17 Thread Waiman Long
locking and queuing overhead. Signed-off-by: Waiman Long waiman.l...@hp.com Acked-by: Rik van Riel r...@redhat.com --- include/linux/mutex.h |3 ++ kernel/mutex.c| 91 - 2 files changed, 93 insertions(+), 1 deletions(-) diff --git

[PATCH v4 1/4] mutex: Move mutex spinning code from sched/core.c back to mutex.c

2013-04-17 Thread Waiman Long
to kernel/mutex.c which is where they should belong. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/sched.h |1 - kernel/mutex.c | 46 ++ kernel/sched/core.c | 45

Re: [PATCH v3 5/5] mutex: Move mutex spinning code from sched/core.c back to mutex.c

2013-04-17 Thread Waiman Long
On 04/17/2013 03:18 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: As mentioned by Ingo, the SCHED_FEAT_OWNER_SPIN scheduler feature bit was really just an early hack to make with/without mutex-spinning testable. So it is no longer necessary. This patch removes the

[PATCH RFC 2/3] mutex: restrict mutex spinning to only one task per mutex

2013-04-04 Thread Waiman Long
% | +0.2% |+1.3%| +--+-+-+-+ It can be seen that this patch improves performance for the fserver and new_fserver workloads while suffering some slight drop in performance for the other workloads. Signed-off-by: Waiman Long

[PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-04 Thread Waiman Long
% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com Reviewed-by: Davidlohr Bueso davidlohr.bu...@hp.com --- arch/x86/include/asm/mutex.h | 16 kernel/mutex.c |9 ++--- kernel/mutex.h |8 3 files changed, 30 insertions(+), 3 deletions

[PATCH RFC 0/3] mutex: Improve mutex performance by doing less atomic-ops spinning

2013-04-04 Thread Waiman Long
%| +--+-+-+--+ So patch 2 is better at low and high load. Patch 3 is better at intermediate load. For other AIM7 workloads, patch 3 is generally better. Waiman Long (3): mutex: Make more scalable by doing less atomic operations mutex: restrict mutex spinning to only

[PATCH RFC 3/3] mutex: dynamically disable mutex spinning at high load

2013-04-04 Thread Waiman Long
and new_fserver workloads while is still generally positive for the other AIM7 workloads. Signed-off-by: Waiman Long waiman.l...@hp.com Reviewed-by: Davidlohr Bueso davidlohr.bu...@hp.com --- kernel/sched/core.c | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git

[PATCH v2 4/4] dcache: don't need to take d_lock in prepend_path()

2013-04-05 Thread Waiman Long
. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 9477d80..e3d6543 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2529,6 +2529,7 @@ static int prepend_name(char **buffer, int

[PATCH v2 RFC 3/4] dcache: change rename_lock to a sequence read/write lock

2013-04-05 Thread Waiman Long
/write lock declaration and access functions. When apply this patch to 3.8 or earlier releases, the unused function d_path_with_unreachable() in fs/dcache.c should be removed to avoid compilation warning. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/autofs4/waitq.c |6 ++-- fs/ceph

[PATCH v2 0/4] dcache: make dcache more scalable on large system

2013-04-05 Thread Waiman Long
can be applied individually. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman Long (4): dcache: Don't take unnecessary lock in d_count update dcache: introduce a new sequence read/write lock type dcache: change rename_lock to a sequence read/write lock dcache: don't need to take d_lock

[PATCH RFC v2 2/4] dcache: introduce a new sequence read/write lock type

2013-04-05 Thread Waiman Long
may be starved if there is a lot of contention. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/seqrwlock.h | 137 + 1 files changed, 137 insertions(+), 0 deletions(-) create mode 100644 include/linux/seqrwlock.h diff --git a/include

[PATCH v2 1/4] dcache: Don't take unnecessary lock in d_count update

2013-04-05 Thread Waiman Long
| 1100-2000 users | +--+---++-+ | high_systime | -0.1% | -0.2% | +1.2% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c

Re: [PATCH v2 1/4] dcache: Don't take unnecessary lock in d_count update

2013-04-05 Thread Waiman Long
On 04/05/2013 01:12 PM, Al Viro wrote: @@ -635,22 +640,14 @@ struct dentry *dget_parent(struct dentry *dentry) { struct dentry *ret; -repeat: - /* -* Don't need rcu_dereference because we re-check it was correct under -* the lock. -*/

Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-08 Thread Waiman Long
On 04/08/2013 08:42 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: In the __mutex_lock_common() function, an initial entry into the lock slow path will cause two atomic_xchg instructions to be issued. Together with the atomic decrement in the fast path, a total of three atomic

Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-08 Thread Waiman Long
On 04/08/2013 10:38 AM, Linus Torvalds wrote: On Mon, Apr 8, 2013 at 5:42 AM, Ingo Molnarmi...@kernel.org wrote: AFAICS the main performance trade-off is the following: when the owner CPU unlocks the mutex, we'll poll it via a read first, which turns the cacheline into shared-read MESI state.

Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-10 Thread Waiman Long
On 04/10/2013 06:28 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: Furthermore, since you are seeing this effect so profoundly, have you considered using another approach, such as queueing all the poll-waiters in some fashion? That would optimize your workload additionally:

Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-10 Thread Waiman Long
On 04/10/2013 06:31 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: That said, the MUTEX_SHOULD_XCHG_COUNT macro should die. Why shouldn't all architectures just consider negative counts to be locked? It doesn't matter that some might only ever see -1. I think so too. However,

[PATCH RFC 1/2] SELinux: reduce overhead of mls_level_isvalid() function call

2013-04-10 Thread Waiman Long
% | +1.1% | +2.4% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com --- security/selinux/ss/mls.c | 38 +++--- 1 files changed, 27 insertions(+), 11 deletions(-) diff --git a/security

[PATCH RFC 2/2] SELinux: Increase ebitmap_node size for 64-bit configuration

2013-04-10 Thread Waiman Long
the overhead ratio at 1/4. This may also improve performance a little bit by making node to node traversal less frequent ( 2) as more bits are available in each node. Signed-off-by: Waiman Long waiman.l...@hp.com --- security/selinux/ss/ebitmap.h |8 +++- 1 files changed, 7 insertions(+), 1

Re: [PATCH RFC 1/3] mutex: Make more scalable by doing less atomic operations

2013-04-10 Thread Waiman Long
On 04/10/2013 01:16 PM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: On 04/10/2013 06:31 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: That said, the MUTEX_SHOULD_XCHG_COUNT macro should die. Why shouldn't all architectures just consider negative counts to be

Re: [PATCH v2 0/4] ipc: reduce ipc lock contention

2013-03-05 Thread Waiman Long
On 03/05/2013 12:10 PM, Rik van Riel wrote: On 03/05/2013 04:35 AM, Davidlohr Bueso wrote: 2) While on an Oracle swingbench DSS (data mining) workload the improvements are not as exciting as with Rik's benchmark, we can see some positive numbers. For an 8 socket machine the following are the

Re: [PATCH v2 0/4] ipc: reduce ipc lock contention

2013-03-05 Thread Waiman Long
On 03/05/2013 03:53 PM, Rik van Riel wrote: On 03/05/2013 03:52 PM, Linus Torvalds wrote: On Tue, Mar 5, 2013 at 11:42 AM, Waiman Long waiman.l...@hp.com wrote: The recommended kernel.sem value from Oracle is 250 32000 100 128. I have tried to reduce the maximum semaphores per array (1st

Re: [PATCH 0/4] dcache: make Oracle more scalable on large systems

2013-02-28 Thread Waiman Long
On 02/22/2013 07:13 PM, Andi Kleen wrote: That seems to me like an application problem - poking at what the kernel is doing via diagnostic interfaces so often that it gets in the way of the kernel actually doing stuff is not a problem the kernel can solve. I agree with you that the application

Re: [PATCH 0/4] dcache: make Oracle more scalable on large systems

2013-02-28 Thread Waiman Long
On 02/28/2013 03:39 PM, Waiman Long wrote: activity level. Most of the d_path() call last for about 1ms. There are a couple of those that last for more than 10ms. A correction. The time unit here should be us, not ms. Sorry for the mistake. -Longman -- To unsubscribe from this list: send

[PATCH 0/4] dcache: make Oracle more scalable on large systems

2013-02-19 Thread Waiman Long
in functions like dput(), but the function itself ran a little bit longer on average. The git-diff test showed no difference in performance. There is a slight increase in system time compensated by a slight decrease in user time. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman Long (4): dcache

[PATCH 1/4] dcache: Don't take unncessary lock in d_count update

2013-02-19 Thread Waiman Long
frequent the cmpxchg instruction is used (d_count 1 or 2), the new code can be faster or slower than the original one. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c| 23 ++ fs/namei.c |2 +- include/linux/dcache.h | 105

[PATCH 4/4] dcache: don't need to take d_lock in prepend_path()

2013-02-19 Thread Waiman Long
. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index b1487e2..0e911fc 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -2547,6 +2547,7 @@ static int prepend_name(char **buffer, int

[PATCH 3/4] dcache: change rename_lock to a sequence read/write lock

2013-02-19 Thread Waiman Long
/write lock declaration and access functions. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/autofs4/waitq.c |6 ++-- fs/ceph/mds_client.c |4 +- fs/cifs/dir.c |4 +- fs/dcache.c| 87 --- fs/nfs/namespace.c

[PATCH 2/4] dcache: introduce a new sequence read/write lock type

2013-02-19 Thread Waiman Long
may be starved if there is a lot of contention. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/seqrwlock.h | 138 + 1 files changed, 138 insertions(+), 0 deletions(-) create mode 100644 include/linux/seqrwlock.h diff --git a/include

Re: [PATCH 0/4] dcache: make Oracle more scalable on large systems

2013-02-21 Thread Waiman Long
On 02/21/2013 07:13 PM, Andi Kleen wrote: Dave Chinnerda...@fromorbit.com writes: On Tue, Feb 19, 2013 at 01:50:55PM -0500, Waiman Long wrote: It was found that the Oracle database software issues a lot of call to the seq_path() kernel function which translates a (dentry, mnt) pair

[PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount

2013-08-05 Thread Waiman Long
lockref* functions are about 10% slower than when there is no contention. Since reference count update is usually a very small part of a typical workload, the actual performance impact of this change is negligible when there is no contention. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/asm

[PATCH v7 3/4] dcache: replace d_lock/d_count by d_lockcnt

2013-08-05 Thread Waiman Long
, they are 8-byte aligned and their combination into a single 8-byte word will not introduce a hole that increase the size of the dentry structure. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c| 54 fs/namei.c

[PATCH v7 0/4] Lockless update of reference count protected by spinlock

2013-08-05 Thread Waiman Long
Gleixner, Andi Kleen and Linus for their valuable input in shaping this patchset. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman Long (4): spinlock: A new lockref structure for lockless update of refcount spinlock: Enable x86 architecture to do lockless refcount update dcache: replace

[PATCH v7 2/4] spinlock: Enable x86 architecture to do lockless refcount update

2013-08-05 Thread Waiman Long
This patch enables the x86 architecture to do lockless reference count update using the generic lockref implementation with default parameters. Only the x86/Kconfig file needs to be changed. Signed-off-by: Waiman Long waiman.l...@hp.com --- arch/x86/Kconfig |3 +++ 1 files changed, 3

[PATCH v7 4/4] dcache: Enable lockless update of dentry's refcount

2013-08-05 Thread Waiman Long
% | +--+---++-+ Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c| 26 ++ include/linux/dcache.h |7 ++- 2 files changed, 20 insertions(+), 13 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 3adb6aa..9a4cf30 100644

Re: [PATCH 0/4] seqlock: Add new blocking reader type use rwlock

2013-08-23 Thread Waiman Long
On 07/03/2013 09:52 PM, Waiman Long wrote: During some perf-record sessions of the kernel running the high_systime workload of the AIM7 benchmark, it was found that quite a large portion of the spinlock contention was due to the perf_event_mmap_event() function itself. This perf kernel function

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

2013-08-26 Thread Waiman Long
On 08/22/2013 09:28 AM, Alexander Fyodorov wrote: 22.08.2013, 05:04, Waiman Longwaiman.l...@hp.com: On 08/21/2013 11:51 AM, Alexander Fyodorov wrote: In this case, we should have smp_wmb() before freeing the lock. The question is whether we need to do a full mb() instead. The x86 ticket

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

2013-08-20 Thread Waiman Long
On 08/20/2013 11:31 AM, Alexander Fyodorov wrote: Hi Waiman, I'm not subscribed to the lkml so I'm writing to you instead. In your patch you put smp_wmb() at the end of spin_unlock(): +static __always_inline void queue_spin_unlock(struct qspinlock *lock) +{ + /* +* This unlock

Re: [PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

2013-08-21 Thread Waiman Long
On 08/21/2013 11:51 AM, Alexander Fyodorov wrote: 21.08.2013, 07:01, Waiman Longwaiman.l...@hp.com: On 08/20/2013 11:31 AM, Alexander Fyodorov wrote: Isn't a race possible if another thread acquires the spinlock in the window between setting lock-locked to 0 and issuing smp_wmb()? Writes from

Re: [PATCH v7 0/4] Lockless update of reference count protected by spinlock

2013-08-13 Thread Waiman Long
On 08/05/2013 11:12 PM, Waiman Long wrote: v6-v7: - Substantially reduce the number of patches from 14 to 4 because a lot of the minor filesystem related changes had been merged to v3.11-rc1. - Remove architecture specific customization (LOCKREF_WAIT_SHIFT LOCKREF_RETRY_COUNT

[PATCH RFC v2 0/2] qspinlock: Introducing a 4-byte queue spinlock

2013-08-13 Thread Waiman Long
to make more efficient use of the lock or finer granularity ones. The main purpose is to make the lock contention problems more tolerable until someone can spend the time and effort to fix them. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman Long (2): qspinlock: Introducing a 4-byte queue

[PATCH RFC v2 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation

2013-08-13 Thread Waiman Long
next to the d_count to be updated whereas mb_cache_spinlock is in a standalone cacheline not shared by the data to be updated. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/asm-generic/qspinlock.h | 207 lib/Kconfig | 25 ++ lib/Makefile

[PATCH RFC v2 2/2] qspinlock x86: Enable x86 to use queue spinlock

2013-08-13 Thread Waiman Long
will be replaced. It only means that the architecture supports the replacement. Actual replacement will only happen if the QSPINLOCK config option is also set. Signed-off-by: Waiman Long waiman.l...@hp.com --- arch/x86/Kconfig |3 +++ arch/x86/include/asm/spinlock.h

Re: [PATCH v3 0/3] qrwlock: Introducing a queue read/write lock implementation

2013-08-13 Thread Waiman Long
On 07/31/2013 08:00 PM, Waiman Long wrote: v2-v3: - Make read lock stealing the default and fair rwlock an option with a different initializer. - In queue_read_lock_slowpath(), check irq_count() and force spinning and lock stealing in interrupt context. - Unify the fair and classic

Re: [PATCH v3 0/3] qrwlock: Introducing a queue read/write lock implementation

2013-08-14 Thread Waiman Long
On 08/14/2013 06:20 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: I would like to share with you a rwlock related system crash that I encountered during my testing with hackbench on an 80-core DL980. The kernel crash because of a watchdog detected hard lockup on cpu 79. The

Re: [PATCH v3 0/3] qrwlock: Introducing a queue read/write lock implementation

2013-08-16 Thread Waiman Long
On 08/14/2013 11:57 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: On 08/14/2013 06:20 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: I would like to share with you a rwlock related system crash that I encountered during my testing with hackbench on an

Re: [PATCH v6 03/14] dcache: Add a new helper function d_count() to return refcount

2013-07-11 Thread Waiman Long
On 07/08/2013 09:09 PM, Waiman Long wrote: This patch adds a new helper function d_count() in dcache.h for returning the current reference count of the dentry object. It should be used by all the files outside of the core dcache.c and namei.c files. I want to know people's thought of spinning

[PATCH RFC 2/2] x86 qrwlock: Enable x86 to use queue read/write lock

2013-07-12 Thread Waiman Long
This patch makes the necessary changes at the x86 architecture specific layer to enable the presence of the CONFIG_QUEUE_RWLOCK kernel option to replace the plain read/write lock by the queue read/write lock. Signed-off-by: Waiman Long waiman.l...@hp.com --- arch/x86/Kconfig

[PATCH RFC 0/2] qrwlock: Introducing a queue read/write lock implementation

2013-07-12 Thread Waiman Long
. By just replacing the current read/write lock with the queue read/write lock, we can have a faster and more deterministic system. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman Long (2): qrwlock: A queue read/write lock implementation x86 qrwlock: Enable x86 to use queue read/write lock arch

[PATCH RFC 1/2] qrwlock: A queue read/write lock implementation

2013-07-12 Thread Waiman Long
% |+0.9% | |new_fserver (HT off)|-1.2%| +29.8% | +40.5% | ++-+--+---+ Signed-off-by: Waiman Long waiman.l...@hp.com --- include/asm-generic/qrwlock.h | 124 + lib/Kconfig

Re: [PATCH RFC 1/2] qrwlock: A queue read/write lock implementation

2013-07-15 Thread Waiman Long
On 07/15/2013 10:39 AM, Steven Rostedt wrote: On Fri, 2013-07-12 at 21:34 -0400, Waiman Long wrote: Signed-off-by: Waiman Longwaiman.l...@hp.com --- +/* + * The queue read/write lock data structure + * The reader stealing flag, if sea,t will enable reader at the head of the sea,t? Should

Re: [PATCH v6 01/14] spinlock: A new lockref structure for lockless update of refcount

2013-07-15 Thread Waiman Long
On 07/13/2013 12:58 PM, Masami Hiramatsu wrote: Hi, (2013/07/09 10:09), Waiman Long wrote: +/** + * lockref_put_or_lock - decrements count unless count = 1 before decrement + * @lockcnt: pointer to lockref structure + * Return: 1 if count updated successfully or 0 if count = 1 and lock taken

Re: [PATCH v5 01/12] spinlock: A new lockref structure for lockless update of refcount

2013-07-15 Thread Waiman Long
On 07/15/2013 10:41 AM, Thomas Gleixner wrote: On Mon, 8 Jul 2013, Waiman Long wrote: On 07/05/2013 02:59 PM, Thomas Gleixner wrote: On Fri, 5 Jul 2013, Waiman Long wrote: I think it is OK to add the GENERIC option, but I would like to make available a slightly different set of options: 1

Re: [PATCH RFC 1/2] qrwlock: A queue read/write lock implementation

2013-07-15 Thread Waiman Long
On 07/15/2013 06:31 PM, Thomas Gleixner wrote: On Fri, 12 Jul 2013, Waiman Long wrote: In term of single-thread performance (no contention), a 256K lock/unlock loop was run on a 2.4GHz Westmere x86-64 CPU. The following table shows the average time for a single lock/unlock sequence: Lock Type

Re: [PATCH v5 01/12] spinlock: A new lockref structure for lockless update of refcount

2013-07-15 Thread Waiman Long
On 07/15/2013 07:47 PM, Thomas Gleixner wrote: On Mon, 15 Jul 2013, Waiman Long wrote: On 07/15/2013 10:41 AM, Thomas Gleixner wrote: On Mon, 8 Jul 2013, Waiman Long wrote: Sigh. GENERIC means, that you use the generic implementation, ARCH means the architecture has a private implementation

[PATCH RFC 0/2] Lockless update of reference count protected by spinlock

2013-06-19 Thread Waiman Long
. The d_lock and d_count fields of the struct dentry in dcache.h was modified to use the new mechanism. This serves as an example of how to convert existing spinlock and reference count combo to use the new way of locklessly updating the reference count. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman

[PATCH RFC 1/2] spinlock: New spinlock_refcount.h for lockless update of refcount

2013-06-19 Thread Waiman Long
. x86 32-bit SMP, CONFIG_DEBUG_SPINLOCK=n 5. x86 32-bit SMP, CONFIG_DEBUG_SPINLOCK=y Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/spinlock_refcount.h | 145 + include/linux/spinlock_types.h| 19 + 2 files changed, 164 insertions

[PATCH RFC 2/2] dcache: Locklessly update d_count whenever possible

2013-06-19 Thread Waiman Long
% | | shared | -0.1% | 0.0% | -0.1% | +--+---++-+ There are slight drops in performance for fsever and new_fserver workloads, but slight increase in the high_systime workload. Signed-off-by: Waiman Long

Re: [PATCH RFC 1/2] qrwlock: A queue read/write lock implementation

2013-07-18 Thread Waiman Long
On 07/18/2013 03:42 AM, Ingo Molnar wrote: * Waiman Longwaiman.l...@hp.com wrote: + *stealing the lock if come at the right moment, the granting of the + *lock is mostly in FIFO order. + * 2. It is faster in high contention situation. Again, why is it faster? The current rwlock

Re: [PATCH RFC 1/2] qrwlock: A queue read/write lock implementation

2013-07-18 Thread Waiman Long
On 07/18/2013 06:22 AM, Thomas Gleixner wrote: Waiman, On Mon, 15 Jul 2013, Waiman Long wrote: On 07/15/2013 06:31 PM, Thomas Gleixner wrote: On Fri, 12 Jul 2013, Waiman Long wrote: Apparently, the regular read/write lock performs even better than the queue read/write lock in some cases

Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
On 09/07/2013 02:07 PM, Al Viro wrote: On Sat, Sep 07, 2013 at 10:52:02AM -0700, Linus Torvalds wrote: So I think we could make a more complicated data structure that looks something like this: struct seqlock_retry { unsigned int seq_no; int state; }; and pass that

[PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
-systime workload, the amount of spinlock contention contributed by running perf without this patch was about 16%. With this patch, the spinlock contention caused by the running of perf will go away and we will have a more accurate perf profile. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs

[PATCH v4 0/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
to prevent live-lock. - Make code re-factoring suggested by George Spelvin. Waiman Long (1): dcache: Translating dentry into pathname without taking rename_lock fs/dcache.c | 196 --- 1 files changed, 133 insertions(+), 63 deletions

Re: [PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
On 09/09/2013 01:45 PM, Linus Torvalds wrote: On Mon, Sep 9, 2013 at 10:29 AM, Al Virov...@zeniv.linux.org.uk wrote: I'm not sure I like mixing rcu_read_lock() into that - d_path() and friends can do that themselves just fine (it needs to be taken when seq is even), and e.g. d_walk() doesn't

Re: [PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
On 09/09/2013 01:29 PM, Al Viro wrote: On Mon, Sep 09, 2013 at 12:18:13PM -0400, Waiman Long wrote: +/** + * read_seqbegin_or_lock - begin a sequence number check or locking block + * lock: sequence lock + * seq : sequence number to be checked + * + * First try it once optimistically without

Re: [PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
On 09/09/2013 02:36 PM, Al Viro wrote: On Mon, Sep 09, 2013 at 07:21:11PM +0100, Al Viro wrote: Actually, it's better for prepend_path() as well, because it's actually rcu_read_lock(); seq = read_seqbegin(rename_lock); again: if (error) goto

Re: [PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
On 09/09/2013 03:28 PM, Al Viro wrote: On Mon, Sep 09, 2013 at 08:10:29PM +0100, Al Viro wrote: On Mon, Sep 09, 2013 at 02:46:57PM -0400, Waiman Long wrote: I am fine with your proposed change as long as it gets the job done. I suspect that the real problem is the unlock part

Re: [PATCH v4 1/1] dcache: Translating dentry into pathname without taking rename_lock

2013-09-09 Thread Waiman Long
On 09/09/2013 08:40 PM, George Spelvin wrote: I'm really wondering about only trying once before taking the write lock. Yes, using the lsbit is a cute hack, but are we using it for its cuteness rather than its effectiveness? Renames happen occasionally. If that causes all the current pathname

Re: kernel BUG at fs/dcache.c:648! with v3.11-7890-ge5c832d

2013-09-10 Thread Waiman Long
On 09/10/2013 04:25 PM, Linus Torvalds wrote: On Tue, Sep 10, 2013 at 12:57 PM, Mace Monetamoneta.m...@gmail.com wrote: The (first) patch looks good; no recurrence. It has only taken 3-5 minutes before, and I've been up for about half an hour now. Ok, good. It's pushed out. Al, your third

[PATCH 2/2] dcache: use read_seqlock/unlock() in read_seqbegin_or_lock() friend

2013-09-11 Thread Waiman Long
. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c | 31 --- 1 files changed, 16 insertions(+), 15 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 4d9df3c..8191ca5 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -90,8 +90,8 @@ static struct kmem_cache

[PATCH 1/2] seqlock: Add a new blocking reader type

2013-09-11 Thread Waiman Long
blocking reader will not block other non-blocking readers, but will block other blocking readers and writers. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/linux/seqlock.h | 65 +++--- 1 files changed, 60 insertions(+), 5 deletions(-) diff --git

Re: [PATCH 1/2] seqlock: Add a new blocking reader type

2013-09-11 Thread Waiman Long
On 09/11/2013 10:55 AM, Al Viro wrote: On Wed, Sep 11, 2013 at 10:28:26AM -0400, Waiman Long wrote: The sequence lock (seqlock) was originally designed for the cases where the readers do not need to block the writers by making the readers retry the read operation when the data change. Since

Re: [PATCH 1/2] seqlock: Add a new blocking reader type

2013-09-11 Thread Waiman Long
On 09/11/2013 01:26 PM, Al Viro wrote: On Wed, Sep 11, 2013 at 12:33:35PM -0400, Waiman Long wrote: Folks, any suggestions on better names? The semantics we are getting is I will welcome any better name suggestion and will incorporate that in the patch. FWIW, the suggestions I've seen so

Re: [3.12-rc1] Dependency on module-init-tools = 3.11 ?

2013-09-12 Thread Waiman Long
On 09/12/2013 06:29 AM, Herbert Xu wrote: On Thu, Sep 12, 2013 at 07:20:23PM +0900, Tetsuo Handa wrote: Herbert Xu wrote: The trouble is not all distros will include the softdep modules in the initramfs. So for now I think we will have to live with a fallback. I see. Herbert Xu wrote: OK,

[PATCH 0/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() friend

2013-09-12 Thread Waiman Long
Change log -- v1-v2: - Rename the new seqlock primitives to read_seqexcl_lock* and read_seqexcl_unlock*. - Clarify in the commit log and comments about the exclusive nature of the read lock. Waiman Long (2): seqlock: Add a new locking reader type dcache: get/release read

[PATCH 2/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() friend

2013-09-12 Thread Waiman Long
comments in the code. Signed-off-by: Waiman Long waiman.l...@hp.com --- fs/dcache.c | 31 --- 1 files changed, 16 insertions(+), 15 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c index 4d9df3c..9e88367 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -90,8 +90,8

[PATCH 1/2 v2] seqlock: Add a new locking reader type

2013-09-12 Thread Waiman Long
locking mechanism. This new locking reader will try to take an exclusive lock preventing other writers and locking readers from going forward. However, it won't affect the progress of the other sequence number reading readers as the sequence number won't be changed. Signed-off-by: Waiman Long waiman.l

Re: [PATCH 0/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() friend

2013-09-12 Thread Waiman Long
On 09/12/2013 12:38 PM, Linus Torvalds wrote: On Thu, Sep 12, 2013 at 7:55 AM, Waiman Longwaiman.l...@hp.com wrote: Change log -- v1-v2: - Rename the new seqlock primitives to read_seqexcl_lock* and read_seqexcl_unlock*. Applied. Except I peed in the snow and renamed the

Re: [PATCH 0/2 v2] dcache: get/release read lock in read_seqbegin_or_lock() friend

2013-09-12 Thread Waiman Long
On 09/12/2013 01:30 PM, Linus Torvalds wrote: On Thu, Sep 12, 2013 at 9:38 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Sep 12, 2013 at 7:55 AM, Waiman Longwaiman.l...@hp.com wrote: Change log -- v1-v2: - Rename the new seqlock primitives to read_seqexcl_lock*

[PATCH v3 3/3] qrwlock: Enable fair queue read/write lock behavior

2013-07-31 Thread Waiman Long
-by: Waiman Long waiman.l...@hp.com --- include/linux/rwlock.h | 15 +++ include/linux/rwlock_types.h | 13 + lib/spinlock_debug.c | 19 +++ 3 files changed, 47 insertions(+), 0 deletions(-) diff --git a/include/linux/rwlock.h b/include/linux

[PATCH v3 2/3] qrwlock x86: Enable x86 to use queue read/write lock

2013-07-31 Thread Waiman Long
that the classic read/write lock will be replaced. It only means that the architecture supports the replacement. Actual replacement will only happen if the QUEUE_RWLOCK config option is also set. Signed-off-by: Waiman Long waiman.l...@hp.com --- arch/x86/Kconfig |3 +++ arch

[PATCH v3 1/3] qrwlock: A queue read/write lock implementation

2013-07-31 Thread Waiman Long
lock is not. So it is not a very good replacement for ticket spinlock. Signed-off-by: Waiman Long waiman.l...@hp.com --- include/asm-generic/qrwlock.h | 239 lib/Kconfig | 23 lib/Makefile |1 + lib/qrwlock.c

[PATCH v3 0/3] qrwlock: Introducing a queue read/write lock implementation

2013-07-31 Thread Waiman Long
lock support on x86 architecture only. Support for other architectures can be added later on once proper testing is done. Signed-off-by: Waiman Long waiman.l...@hp.com Waiman Long (3): qrwlock: A queue read/write lock implementation qrwlock x86: Enable x86 to use queue read/write lock qrwlock

  1   2   3   4   5   6   7   8   9   10   >