From: Will Deacon <will.deacon@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
longman@redhat.com, andrea.parri@amarulasolutions.com,
tglx@linutronix.de, bigeasy@linutronix.de
Subject: Re: [PATCH v2 4/4] locking/qspinlock, x86: Provide liveness guarantee
Date: Wed, 10 Oct 2018 17:12:57 +0100 [thread overview]
Message-ID: <20181010161257.GD17340@arm.com> (raw)
In-Reply-To: <20181003130957.183726335@infradead.org>
On Wed, Oct 03, 2018 at 03:03:01PM +0200, Peter Zijlstra wrote:
> On x86 we cannot do fetch_or with a single instruction and thus end up
> using a cmpxchg loop, this reduces determinism. Replace the fetch_or
> with a composite operation: tas-pending + load.
>
> Using two instructions of course opens a window we previously did not
> have. Consider the scenario:
>
>
> CPU0 CPU1 CPU2
>
> 1) lock
> trylock -> (0,0,1)
>
> 2) lock
> trylock /* fail */
>
> 3) unlock -> (0,0,0)
>
> 4) lock
> trylock -> (0,0,1)
>
> 5) tas-pending -> (0,1,1)
> load-val <- (0,1,0) from 3
>
> 6) clear-pending-set-locked -> (0,0,1)
>
> FAIL: _2_ owners
>
> where 5) is our new composite operation. When we consider each part of
> the qspinlock state as a separate variable (as we can when
> _Q_PENDING_BITS == 8) then the above is entirely possible, because
> tas-pending will only RmW the pending byte, so the later load is able
> to observe prior tail and lock state (but not earlier than its own
> trylock, which operates on the whole word, due to coherence).
>
> To avoid this we need 2 things:
>
> - the load must come after the tas-pending (obviously, otherwise it
> can trivially observe prior state).
>
> - the tas-pending must be a full word RmW, it cannot be an xchg8 for
> example, such that we cannot observe other state prior to setting
> pending.
>
> On x86 we can realize this by using "LOCK BTS m32, r32" for
> tas-pending followed by a regular load.
>
> Note that observing later state is not a problem:
>
> - if we fail to observe a later unlock, we'll simply spin-wait for
> that store to become visible.
>
> - if we observe a later xchg_tail, there is no difference from that
> xchg_tail having taken place before the tas-pending.
>
> Cc: mingo@kernel.org
> Cc: tglx@linutronix.de
> Cc: longman@redhat.com
> Cc: andrea.parri@amarulasolutions.com
> Suggested-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> arch/x86/include/asm/qspinlock.h | 15 +++++++++++++++
> kernel/locking/qspinlock.c | 16 +++++++++++++++-
> 2 files changed, 30 insertions(+), 1 deletion(-)
I've failed to break this by thinking really hard, so I've updated Catalin's
TLA model to see if the tools are still happy. I'll get back to you once
they've finished chewing on it.
Will
next prev parent reply other threads:[~2018-10-10 16:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 13:02 [PATCH v2 0/4] locking/qspinlock, x86: Improve determinism for x86 Peter Zijlstra
2018-10-03 13:02 ` [PATCH v2 1/4] locking/qspinlock: Re-order code Peter Zijlstra
2018-10-03 13:02 ` [PATCH v2 2/4] locking/qspinlock: Rework some comments Peter Zijlstra
2018-10-10 16:13 ` Will Deacon
2018-10-03 13:03 ` [PATCH v2 3/4] x86/asm: Simplify GEN_*_RMWcc() macros Peter Zijlstra
2018-10-04 9:18 ` Peter Zijlstra
2018-10-16 16:05 ` [tip:locking/core] x86/asm: 'Simplify' " tip-bot for Peter Zijlstra
2018-10-03 13:03 ` [PATCH v2 4/4] locking/qspinlock, x86: Provide liveness guarantee Peter Zijlstra
2018-10-10 16:12 ` Will Deacon [this message]
2018-10-12 9:22 ` Will Deacon
2018-10-16 16:06 ` [tip:locking/core] " tip-bot for Peter Zijlstra
2018-10-16 16:04 ` [tip:locking/core] locking/qspinlock: Re-order code tip-bot for Peter Zijlstra
2018-10-16 16:04 ` [tip:locking/core] locking/qspinlock: Rework some comments tip-bot for Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181010161257.GD17340@arm.com \
--to=will.deacon@arm.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox