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 wh
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
> > > min
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, Th
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 P
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 int
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? If
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 a
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:
> 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:
> 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 speci
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 su
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 TO_S
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 lea
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? P
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 impl
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
> > >>throughput-optim
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 (TO_SPIN_THRESHOLD/32)
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) futex
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 l
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 nex
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 a
23 matches
Mail list logo
