.
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
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
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
% | +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
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
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
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
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,
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
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
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
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
.
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
% | +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
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
% | +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
.
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
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
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
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
% | +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
% |
+--+---++-+
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
%|
+--+-+-+--+
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
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
.
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
/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
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
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
| 1100-2000 users |
+--+---++-+
| high_systime | -0.1% | -0.2% | +1.2% |
+--+---++-+
Signed-off-by: Waiman Long waiman.l...@hp.com
---
fs/dcache.c
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.
-*/
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
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.
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:
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,
% | +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
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
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
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
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
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
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
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
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
.
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
/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
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
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
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
, 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
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
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
% |
+--+---++-+
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
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
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
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
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
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
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
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
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
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
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
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
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
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
. 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
% |+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
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
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
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
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
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
.
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
. 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
% |
| 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
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
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
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
-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
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
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
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
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
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
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
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
.
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
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
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
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
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,
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
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
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
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
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*
-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
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
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
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 - 100 of 6450 matches
Mail list logo