On Wed, Feb 05, 2014 at 10:10:34PM -0500, Waiman Long wrote:
> On 02/03/2014 06:40 AM, Peter Zijlstra wrote:
> >On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
> >>Light contention is the only case where the qspinlock may not perform as
> >>good as the ticket spinlock. I know this is
On Wed, Feb 05, 2014 at 10:10:34PM -0500, Waiman Long wrote:
On 02/03/2014 06:40 AM, Peter Zijlstra wrote:
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
Light contention is the only case where the qspinlock may not perform as
good as the ticket spinlock. I know this is the most
On 02/03/2014 06:40 AM, Peter Zijlstra wrote:
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
Light contention is the only case where the qspinlock may not perform as
good as the ticket spinlock. I know this is the most common case. However, I
would argue that the slowdown, if any,
On 02/03/2014 06:40 AM, Peter Zijlstra wrote:
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
Light contention is the only case where the qspinlock may not perform as
good as the ticket spinlock. I know this is the most common case. However, I
would argue that the slowdown, if any,
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
>
> Light contention is the only case where the qspinlock may not perform as
> good as the ticket spinlock. I know this is the most common case. However, I
> would argue that the slowdown, if any, will not be really noticeable. This
>
On 01/28/2014 11:49 PM, Waiman Long wrote:
+#endif /* __ASM_GENERIC_QSPINLOCK_H */
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index d2b32ac..f185584 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -223,3 +223,10 @@ endif
config MUTEX_SPIN_ON_OWNER
def_bool
On 01/28/2014 11:49 PM, Waiman Long wrote:
+#endif /* __ASM_GENERIC_QSPINLOCK_H */
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index d2b32ac..f185584 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -223,3 +223,10 @@ endif
config MUTEX_SPIN_ON_OWNER
def_bool
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
Light contention is the only case where the qspinlock may not perform as
good as the ticket spinlock. I know this is the most common case. However, I
would argue that the slowdown, if any, will not be really noticeable. This
is
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
> On 01/31/2014 10:08 AM, Peter Zijlstra wrote:
> >Whereas for the straight cmpxchg() you'd get something relatively simple
> >like:
> >
> > mov %edx,%eax
> > lock cmpxchg %ecx,(%rbx)
> > cmp %edx,%eax
> > jne ...
>
> I believe
On Fri, Jan 31, 2014 at 01:26:29PM -0500, Waiman Long wrote:
> >I don't get why we need the used thing at all; something like:
> >
> >struct qna {
> > int cnt;
> > struct qnode nodes[4];
> >};
> >
> >DEFINE_PER_CPU(struct qna, qna);
> >
> >struct qnode *get_qnode(void)
> >{
> > struct
On 01/31/2014 02:14 PM, George Spelvin wrote:
Yes, we can do something like that. However I think put_qnode() needs to
use atomic dec as well. As a result, we will need 2 additional atomic
operations per slowpath invocation. The code may look simpler, but I
don't think it will be faster than
On 01/31/2014 10:08 AM, Peter Zijlstra wrote:
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
For 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 (in ns) for a single lock/unlock
> Yes, we can do something like that. However I think put_qnode() needs to
> use atomic dec as well. As a result, we will need 2 additional atomic
> operations per slowpath invocation. The code may look simpler, but I
> don't think it will be faster than what I am currently doing as the
>
On 01/30/2014 02:35 PM, Peter Zijlstra wrote:
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be
On 01/30/2014 02:28 PM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 11:00:30AM -0800, Tim Chen wrote:
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
+/**
+ * queue_spin_lock_slowpath - acquire the queue spinlock
+ * @lock: Pointer to queue spinlock structure
+ */
+void
On 01/30/2014 02:00 PM, Tim Chen wrote:
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
+/**
+ * queue_spin_lock_slowpath - acquire the queue spinlock
+ * @lock: Pointer to queue spinlock structure
+ */
+void queue_spin_lock_slowpath(struct qspinlock *lock)
+{
+ unsigned int
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
> For 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 (in ns) for a single lock/unlock sequence
> (including the looping and
On 01/30/2014 02:00 PM, Tim Chen wrote:
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
+/**
+ * queue_spin_lock_slowpath - acquire the queue spinlock
+ * @lock: Pointer to queue spinlock structure
+ */
+void queue_spin_lock_slowpath(struct qspinlock *lock)
+{
+ unsigned int
On 01/30/2014 02:28 PM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 11:00:30AM -0800, Tim Chen wrote:
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
+/**
+ * queue_spin_lock_slowpath - acquire the queue spinlock
+ * @lock: Pointer to queue spinlock structure
+ */
+void
On 01/30/2014 02:35 PM, Peter Zijlstra wrote:
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be
Yes, we can do something like that. However I think put_qnode() needs to
use atomic dec as well. As a result, we will need 2 additional atomic
operations per slowpath invocation. The code may look simpler, but I
don't think it will be faster than what I am currently doing as the
cases
On 01/31/2014 10:08 AM, Peter Zijlstra wrote:
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
For 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 (in ns) for a single lock/unlock
On 01/31/2014 02:14 PM, George Spelvin wrote:
Yes, we can do something like that. However I think put_qnode() needs to
use atomic dec as well. As a result, we will need 2 additional atomic
operations per slowpath invocation. The code may look simpler, but I
don't think it will be faster than
On Fri, Jan 31, 2014 at 01:26:29PM -0500, Waiman Long wrote:
I don't get why we need the used thing at all; something like:
struct qna {
int cnt;
struct qnode nodes[4];
};
DEFINE_PER_CPU(struct qna, qna);
struct qnode *get_qnode(void)
{
struct qna *qna =
On Fri, Jan 31, 2014 at 02:24:33PM -0500, Waiman Long wrote:
On 01/31/2014 10:08 AM, Peter Zijlstra wrote:
Whereas for the straight cmpxchg() you'd get something relatively simple
like:
mov %edx,%eax
lock cmpxchg %ecx,(%rbx)
cmp %edx,%eax
jne ...
I believe the speeds of the
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
For 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 (in ns) for a single lock/unlock sequence
(including the looping and timing
> > > + /*
> > > + * Set up the new cpu code to be exchanged
> > > + */
> > > + my_qcode = SET_QCODE(cpu_nr, qn_idx);
> > > +
> >
> > If we get interrupted here before we have a chance to set the used flag,
> > the interrupt handler could pick up the same qnode if it tries to
> > acquire
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
> This patch introduces a new queue spinlock implementation that can
> serve as an alternative to the default ticket spinlock. Compared with
> the ticket spinlock, this queue spinlock should be almost as fair as
> the ticket spinlock. It
On Thu, Jan 30, 2014 at 11:00:30AM -0800, Tim Chen wrote:
> On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
>
> > +/**
> > + * queue_spin_lock_slowpath - acquire the queue spinlock
> > + * @lock: Pointer to queue spinlock structure
> > + */
> > +void queue_spin_lock_slowpath(struct
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
> +/**
> + * queue_spin_lock_slowpath - acquire the queue spinlock
> + * @lock: Pointer to queue spinlock structure
> + */
> +void queue_spin_lock_slowpath(struct qspinlock *lock)
> +{
> + unsigned int cpu_nr, qn_idx;
> + struct qnode
On 01/28/2014 01:19 PM, Waiman Long wrote:
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be almost as fair as
the ticket spinlock. It has about the same
On 01/28/2014 01:19 PM, Waiman Long wrote:
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be almost as fair as
the ticket spinlock. It has about the same
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
+/**
+ * queue_spin_lock_slowpath - acquire the queue spinlock
+ * @lock: Pointer to queue spinlock structure
+ */
+void queue_spin_lock_slowpath(struct qspinlock *lock)
+{
+ unsigned int cpu_nr, qn_idx;
+ struct qnode *node,
On Thu, Jan 30, 2014 at 11:00:30AM -0800, Tim Chen wrote:
On Tue, 2014-01-28 at 13:19 -0500, Waiman Long wrote:
+/**
+ * queue_spin_lock_slowpath - acquire the queue spinlock
+ * @lock: Pointer to queue spinlock structure
+ */
+void queue_spin_lock_slowpath(struct qspinlock *lock)
On Tue, Jan 28, 2014 at 01:19:10PM -0500, Waiman Long wrote:
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be almost as fair as
the ticket spinlock. It has
+ /*
+ * Set up the new cpu code to be exchanged
+ */
+ my_qcode = SET_QCODE(cpu_nr, qn_idx);
+
If we get interrupted here before we have a chance to set the used flag,
the interrupt handler could pick up the same qnode if it tries to
acquire queued spin lock. Then we
On 01/28/2014 07:20 PM, Andi Kleen wrote:
So the 1-2 threads case is the standard case on a small
system, isn't it? This may well cause regressions.
Yes, it is possible that in a lightly contended case, the queue spinlock
maybe a bit slower because of the slowpath overhead. I observed some
On 01/28/2014 07:20 PM, Andi Kleen wrote:
So the 1-2 threads case is the standard case on a small
system, isn't it? This may well cause regressions.
Yes, it is possible that in a lightly contended case, the queue spinlock
maybe a bit slower because of the slowpath overhead. I observed some
> So the 1-2 threads case is the standard case on a small
> system, isn't it? This may well cause regressions.
Well, the common case should be uncontended, which is faster.
But yes, testing would be nice.
>> In the extremely unlikely case that all the queue node entries are
>> used up, the
So the 1-2 threads case is the standard case on a small
system, isn't it? This may well cause regressions.
> In the extremely unlikely case that all the queue node entries are
> used up, the current code will fall back to busy spinning without
> waiting in a queue with warning message.
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be almost as fair as
the ticket spinlock. It has about the same speed in single-thread and
it can be much faster
This patch introduces a new queue spinlock implementation that can
serve as an alternative to the default ticket spinlock. Compared with
the ticket spinlock, this queue spinlock should be almost as fair as
the ticket spinlock. It has about the same speed in single-thread and
it can be much faster
So the 1-2 threads case is the standard case on a small
system, isn't it? This may well cause regressions.
In the extremely unlikely case that all the queue node entries are
used up, the current code will fall back to busy spinning without
waiting in a queue with warning message.
So the 1-2 threads case is the standard case on a small
system, isn't it? This may well cause regressions.
Well, the common case should be uncontended, which is faster.
But yes, testing would be nice.
In the extremely unlikely case that all the queue node entries are
used up, the current
44 matches
Mail list logo
