On 07/22/2013 06:34 AM, Ingo Molnar wrote:
* Waiman Long wrote:
I had run some performance tests using the fserver and new_fserver
benchmarks (on ext4 filesystems) of the AIM7 test suite on a 80-core
DL980 with HT on. The following kernels were used:
1. Modified 3.10.1 kernel with
On 07/21/2013 01:42 AM, Raghavendra K T wrote:
On 07/18/2013 07:49 PM, Waiman Long wrote:
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:
[...]
+ * an
On 07/21/2013 01:42 AM, Raghavendra K T wrote:
On 07/18/2013 07:49 PM, Waiman Long wrote:
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:
[...]
+ * an
On 07/22/2013 06:34 AM, Ingo Molnar wrote:
* Waiman Longwaiman.l...@hp.com wrote:
I had run some performance tests using the fserver and new_fserver
benchmarks (on ext4 filesystems) of the AIM7 test suite on a 80-core
DL980 with HT on. The following kernels were used:
1. Modified 3.10.1
* Waiman Long wrote:
> I had run some performance tests using the fserver and new_fserver
> benchmarks (on ext4 filesystems) of the AIM7 test suite on a 80-core
> DL980 with HT on. The following kernels were used:
>
> 1. Modified 3.10.1 kernel with mb_cache_spinlock in fs/mbcache.c
>
* Waiman Long waiman.l...@hp.com wrote:
I had run some performance tests using the fserver and new_fserver
benchmarks (on ext4 filesystems) of the AIM7 test suite on a 80-core
DL980 with HT on. The following kernels were used:
1. Modified 3.10.1 kernel with mb_cache_spinlock in
On 07/18/2013 07:49 PM, Waiman Long wrote:
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:
[...]
+ * an increase in lock size is not an issue.
So is it
On 07/18/2013 07:49 PM, Waiman Long wrote:
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:
[...]
+ * an increase in lock size is not an issue.
So is it
On 07/19/2013 05:11 PM, George Spelvin wrote:
What I have in mind is to have 2 separate rwlock initializers - one for
fair and one for reader-bias behavior. So the lock owners can decide
what behavior do they want with a one line change.
That's definitely a nicer patch, if it will work. I was
> What I have in mind is to have 2 separate rwlock initializers - one for
> fair and one for reader-bias behavior. So the lock owners can decide
> what behavior do they want with a one line change.
That's definitely a nicer patch, if it will work. I was imagining that,
even for a single (type
On 07/18/2013 02:46 PM, George Spelvin wrote:
Thank for the revision, I will make such a change in the next version of
my patch.
I'm relying on you to correct any technical errors in my description.
I just meant "something more like this", not impose that exact wording.
As I said in my
On 07/19/2013 04:40 AM, Ingo Molnar wrote:
* Waiman Long wrote:
On 07/18/2013 03:42 AM, Ingo Molnar wrote:
* Waiman Long 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.
* Waiman Long wrote:
> On 07/18/2013 03:42 AM, Ingo Molnar wrote:
> >* Waiman Long 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
* Waiman Long waiman.l...@hp.com wrote:
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.
On 07/19/2013 04:40 AM, Ingo Molnar wrote:
* Waiman Longwaiman.l...@hp.com wrote:
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
On 07/18/2013 02:46 PM, George Spelvin wrote:
Thank for the revision, I will make such a change in the next version of
my patch.
I'm relying on you to correct any technical errors in my description.
I just meant something more like this, not impose that exact wording.
As I said in my response
What I have in mind is to have 2 separate rwlock initializers - one for
fair and one for reader-bias behavior. So the lock owners can decide
what behavior do they want with a one line change.
That's definitely a nicer patch, if it will work. I was imagining that,
even for a single (type of)
On 07/19/2013 05:11 PM, George Spelvin wrote:
What I have in mind is to have 2 separate rwlock initializers - one for
fair and one for reader-bias behavior. So the lock owners can decide
what behavior do they want with a one line change.
That's definitely a nicer patch, if it will work. I was
> Thank for the revision, I will make such a change in the next version of
> my patch.
I'm relying on you to correct any technical errors in my description.
I just meant "something more like this", not impose that exact wording.
> As I said in my response to Ingo, that change will make the lock
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 07/18/2013 03:42 AM, Ingo Molnar wrote:
* Waiman Long 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 implementation suffers
In the interest of more useful Kconfig help, could I recommend the
following text:
config QUEUE_RWLOCK
bool "Generic queue read/write lock"
depends on ARCH_QUEUE_RWLOCK
help
Use an alternative reader-writer lock (rwlock) implementation,
optimized for
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. This is probably due to the
> > The
* Waiman Long 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 implementation suffers from a thundering
* Waiman Long waiman.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 implementation suffers from a
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. This is probably due to the
The regular
In the interest of more useful Kconfig help, could I recommend the
following text:
config QUEUE_RWLOCK
bool Generic queue read/write lock
depends on ARCH_QUEUE_RWLOCK
help
Use an alternative reader-writer lock (rwlock) implementation,
optimized for
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.
Thank for the revision, I will make such a change in the next version of
my patch.
I'm relying on you to correct any technical errors in my description.
I just meant something more like this, not impose that exact wording.
As I said in my response to Ingo, that change will make the lock more
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 Fri, 12 Jul 2013, Waiman Long wrote:
> This patch introduces a read/write lock implementation that put waiting
> readers and writers into a queue instead of actively contending the
> lock like the regular read/write lock. This will improve performance in
> highly contended situation by
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 Long
---
+/*
+ * 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 be "if set,".
On Fri, 2013-07-12 at 21:34 -0400, Waiman Long wrote:
> Signed-off-by: Waiman Long
> ---
> include/asm-generic/qrwlock.h | 124 +
> lib/Kconfig | 11 ++
> lib/Makefile |1 +
> lib/qrwlock.c | 246
>
On Fri, 2013-07-12 at 21:34 -0400, Waiman Long wrote:
Signed-off-by: Waiman Long waiman.l...@hp.com
---
include/asm-generic/qrwlock.h | 124 +
lib/Kconfig | 11 ++
lib/Makefile |1 +
lib/qrwlock.c | 246
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 Fri, 12 Jul 2013, Waiman Long wrote:
This patch introduces a read/write lock implementation that put waiting
readers and writers into a queue instead of actively contending the
lock like the regular read/write lock. This will improve performance in
highly contended situation by reducing
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
This patch introduces a read/write lock implementation that put waiting
readers and writers into a queue instead of actively contending the
lock like the regular read/write lock. This will improve performance in
highly contended situation by reducing the cache line bouncing effect.
In addition,
This patch introduces a read/write lock implementation that put waiting
readers and writers into a queue instead of actively contending the
lock like the regular read/write lock. This will improve performance in
highly contended situation by reducing the cache line bouncing effect.
In addition,
40 matches
Mail list logo
