On 09/23/2016 09:02 AM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
Locking was done mostly by lock stealing. This is where most of the
performance benefit comes from, not optimistic spinning.
How does the lock latency distribution of all this look like and how fair
is the
On 09/23/2016 09:02 AM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
Locking was done mostly by lock stealing. This is where most of the
performance benefit comes from, not optimistic spinning.
How does the lock latency distribution of all this look like and how fair
is the
On Thu, 22 Sep 2016, Waiman Long wrote:
> On 09/22/2016 04:38 PM, Thomas Gleixner wrote:
> > > wait-wake futex PI futexTO futex
> > > ---
> > > max time3.49s50.91s 2.65s
> > >
On Thu, 22 Sep 2016, Waiman Long wrote:
> On 09/22/2016 04:38 PM, Thomas Gleixner wrote:
> > > wait-wake futex PI futexTO futex
> > > ---
> > > max time3.49s50.91s 2.65s
> > >
On 09/22/2016 05:41 PM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
BTW, my initial attempt for the new futex was to use the same workflow as
the PI futexes, but use mutex which has optimistic spinning instead of
rt_mutex.
Btw,
On 09/22/2016 05:41 PM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
BTW, my initial attempt for the new futex was to use the same workflow as
the PI futexes, but use mutex which has optimistic spinning instead of
rt_mutex.
Btw,
On 09/22/2016 04:38 PM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
BTW, my initial attempt for the new futex was to use the same workflow as the
PI futexes, but use mutex which has optimistic spinning instead of rt_mutex.
That version can double the throughput compared with
On 09/22/2016 04:38 PM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
BTW, my initial attempt for the new futex was to use the same workflow as the
PI futexes, but use mutex which has optimistic spinning instead of rt_mutex.
That version can double the throughput compared with
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
> On Thu, 22 Sep 2016, Waiman Long wrote:
>
> > BTW, my initial attempt for the new futex was to use the same workflow as
> > the PI futexes, but use mutex which has optimistic spinning instead of
> > rt_mutex.
>
> Btw, Thomas, do you still have any
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
> On Thu, 22 Sep 2016, Waiman Long wrote:
>
> > BTW, my initial attempt for the new futex was to use the same workflow as
> > the PI futexes, but use mutex which has optimistic spinning instead of
> > rt_mutex.
>
> Btw, Thomas, do you still have any
On Thu, 22 Sep 2016, Waiman Long wrote:
BTW, my initial attempt for the new futex was to use the same workflow
as the PI futexes, but use mutex which has optimistic spinning instead
of rt_mutex.
Btw, Thomas, do you still have any interest pursuing this for rtmutexes from
-rt into mainline?
On Thu, 22 Sep 2016, Waiman Long wrote:
BTW, my initial attempt for the new futex was to use the same workflow
as the PI futexes, but use mutex which has optimistic spinning instead
of rt_mutex.
Btw, Thomas, do you still have any interest pursuing this for rtmutexes from
-rt into mainline?
On 09/22/2016 04:26 PM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
On 09/22/2016 09:34 AM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
I'd leave out the TO part entirely (or only mention it in changelogs).
That is, I'd call the futex ops: FUTEX_LOCK
On 09/22/2016 04:26 PM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Waiman Long wrote:
On 09/22/2016 09:34 AM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
I'd leave out the TO part entirely (or only mention it in changelogs).
That is, I'd call the futex ops: FUTEX_LOCK
On Thu, 22 Sep 2016, Waiman Long wrote:
> BTW, my initial attempt for the new futex was to use the same workflow as the
> PI futexes, but use mutex which has optimistic spinning instead of rt_mutex.
> That version can double the throughput compared with PI futexes but still far
> short of what can
On Thu, 22 Sep 2016, Waiman Long wrote:
> BTW, my initial attempt for the new futex was to use the same workflow as the
> PI futexes, but use mutex which has optimistic spinning instead of rt_mutex.
> That version can double the throughput compared with PI futexes but still far
> short of what can
On 09/22/2016 04:08 PM, Waiman Long wrote:
On 09/22/2016 11:11 AM, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> Also what's the reason that we can't do probabilistic spinning for
>
On 09/22/2016 04:08 PM, Waiman Long wrote:
On 09/22/2016 11:11 AM, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> Also what's the reason that we can't do probabilistic spinning for
>
On Thu, 22 Sep 2016, Waiman Long wrote:
> On 09/22/2016 09:34 AM, Thomas Gleixner wrote:
> > On Thu, 22 Sep 2016, Peter Zijlstra wrote:
> > >
> > > I'd leave out the TO part entirely (or only mention it in changelogs).
> > >
> > > That is, I'd call the futex ops: FUTEX_LOCK and FUTEX_UNLOCK.
> >
On Thu, 22 Sep 2016, Waiman Long wrote:
> On 09/22/2016 09:34 AM, Thomas Gleixner wrote:
> > On Thu, 22 Sep 2016, Peter Zijlstra wrote:
> > >
> > > I'd leave out the TO part entirely (or only mention it in changelogs).
> > >
> > > That is, I'd call the futex ops: FUTEX_LOCK and FUTEX_UNLOCK.
> >
On 09/22/2016 11:11 AM, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> Also what's the reason that we can't do probabilistic spinning for
> FUTEX_WAIT and have to add yet another
On 09/22/2016 11:11 AM, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> Also what's the reason that we can't do probabilistic spinning for
> FUTEX_WAIT and have to add yet another
On 09/22/2016 09:34 AM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
I'd leave out the TO part entirely (or only mention it in changelogs).
That is, I'd call the futex ops: FUTEX_LOCK and FUTEX_UNLOCK.
That brings me to a different question:
How is user space going to
On 09/22/2016 09:34 AM, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
I'd leave out the TO part entirely (or only mention it in changelogs).
That is, I'd call the futex ops: FUTEX_LOCK and FUTEX_UNLOCK.
That brings me to a different question:
How is user space going to
On 09/22/2016 09:23 AM, Peter Zijlstra wrote:
On Tue, Sep 20, 2016 at 09:42:41AM -0400, Waiman Long wrote:
+/*
+ * Spinning threshold before enabling lock handoff.
+ * Each sleep will decrement the threshold by 1/32 of the start value.
+ */
+#define TO_SPIN_THRESHOLD (1<< 13)
+#define
On 09/22/2016 09:23 AM, Peter Zijlstra wrote:
On Tue, Sep 20, 2016 at 09:42:41AM -0400, Waiman Long wrote:
+/*
+ * Spinning threshold before enabling lock handoff.
+ * Each sleep will decrement the threshold by 1/32 of the start value.
+ */
+#define TO_SPIN_THRESHOLD (1<< 13)
+#define
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> Also what's the reason that we can't do probabilistic spinning for
> FUTEX_WAIT and have to add yet another specialized variant of futexes?
Where would this
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> Also what's the reason that we can't do probabilistic spinning for
> FUTEX_WAIT and have to add yet another specialized variant of futexes?
Where would this
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
> On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> > Also what's the reason that we can't do probabilistic spinning for
> > FUTEX_WAIT and have to add yet another specialized variant of futexes?
>
> Where would this leave the respective FUTEX_WAKE? A nop?
On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
> On Thu, 22 Sep 2016, Thomas Gleixner wrote:
> > Also what's the reason that we can't do probabilistic spinning for
> > FUTEX_WAIT and have to add yet another specialized variant of futexes?
>
> Where would this leave the respective FUTEX_WAKE? A nop?
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
> On 09/21/2016 02:59 AM, Mike Galbraith wrote:
> >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> >>This patch introduces a new futex
On Thu, 22 Sep 2016, Thomas Gleixner wrote:
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
> On 09/21/2016 02:59 AM, Mike Galbraith wrote:
> >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> >>This patch introduces a new futex
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
> On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
> > On 09/21/2016 02:59 AM, Mike Galbraith wrote:
> > >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> > >>This patch introduces a new futex implementation called
> >
On Thu, 22 Sep 2016, Peter Zijlstra wrote:
> On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
> > On 09/21/2016 02:59 AM, Mike Galbraith wrote:
> > >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> > >>This patch introduces a new futex implementation called
> >
On Tue, Sep 20, 2016 at 09:42:41AM -0400, Waiman Long wrote:
> +/*
> + * Spinning threshold before enabling lock handoff.
> + * Each sleep will decrement the threshold by 1/32 of the start value.
> + */
> +#define TO_SPIN_THRESHOLD(1 << 13)
> +#define TO_SLEEP_DECREMENT
On Tue, Sep 20, 2016 at 09:42:41AM -0400, Waiman Long wrote:
> +/*
> + * Spinning threshold before enabling lock handoff.
> + * Each sleep will decrement the threshold by 1/32 of the start value.
> + */
> +#define TO_SPIN_THRESHOLD(1 << 13)
> +#define TO_SLEEP_DECREMENT
On 09/22/2016 03:49 AM, Peter Zijlstra wrote:
On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
On 09/21/2016 02:59 AM, Mike Galbraith wrote:
On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
This patch introduces a new futex implementation called
throughput-optimized (TO)
On 09/22/2016 03:49 AM, Peter Zijlstra wrote:
On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
On 09/21/2016 02:59 AM, Mike Galbraith wrote:
On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
This patch introduces a new futex implementation called
throughput-optimized (TO)
On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
> On 09/21/2016 02:59 AM, Mike Galbraith wrote:
> >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> >>This patch introduces a new futex implementation called
> >>throughput-optimized (TO) futexes.
> >nit: 'TO' sounds way too much
On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote:
> On 09/21/2016 02:59 AM, Mike Galbraith wrote:
> >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> >>This patch introduces a new futex implementation called
> >>throughput-optimized (TO) futexes.
> >nit: 'TO' sounds way too much
On 09/21/2016 02:59 AM, Mike Galbraith wrote:
On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
This patch introduces a new futex implementation called
throughput-optimized (TO) futexes.
nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as
shorthand for timeout in the
On 09/21/2016 02:59 AM, Mike Galbraith wrote:
On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
This patch introduces a new futex implementation called
throughput-optimized (TO) futexes.
nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as
shorthand for timeout in the
On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> This patch introduces a new futex implementation called
> throughput-optimized (TO) futexes.
nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as
shorthand for timeout in the next patch.
> /*
> ->>
On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote:
> This patch introduces a new futex implementation called
> throughput-optimized (TO) futexes.
nit: 'TO' sounds way too much like timeout... TP? You even use 'to' as
shorthand for timeout in the next patch.
> /*
> ->>
This patch introduces a new futex implementation called
throughput-optimized (TO) futexes. The goal of this new futex
type is to maximize locking throughput at the expense of fairness
and deterministic latency. Its throughput is higher than that of
the wait-wake futexes especially on systems with
This patch introduces a new futex implementation called
throughput-optimized (TO) futexes. The goal of this new futex
type is to maximize locking throughput at the expense of fairness
and deterministic latency. Its throughput is higher than that of
the wait-wake futexes especially on systems with
46 matches
Mail list logo
