From: Peter Zijlstra <peterz@infradead.org>
To: Will Deacon <will.deacon@arm.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
longman@redhat.com, andrea.parri@amarulasolutions.com,
tglx@linutronix.de
Subject: Re: [RFC][PATCH 2/3] locking/qspinlock: Rework some comments
Date: Tue, 2 Oct 2018 15:43:58 +0200 [thread overview]
Message-ID: <20181002134358.GD26858@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20181002132005.GE16422@arm.com>
On Tue, Oct 02, 2018 at 02:20:05PM +0100, Will Deacon wrote:
> > Ah, so the reason I write it like so is because when we get here,
> > val.locked_pending == 0, per the atomic_cond_read_acquire() condition.
>
> Ah, and I vaguely remember discussing this before. The way I read these
> transition diagrams, I find it most useful if they correspond to the lock
> word in memory. That way, it makes it clear about exactly which fields are
> stable, and which can be concurrently modified. So in the comment above,
> saying:
>
> *,*,0 -> *,*,1 : lock, contended
>
> is really helpful, because it clearly says "we're taking the lock, but the
> rest of the lock word could be modified by others at the same time", whereas
> saying:
>
> *,0,0 -> *,0,1 : lock, contended
>
> implies to me that pending is stable and cannot be set concurrently.
Fair enough, will restore.
next prev parent reply other threads:[~2018-10-02 13:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 11:01 [RFC][PATCH 0/3] locking/qspinlock: Improve determinism for x86 Peter Zijlstra
2018-09-26 11:01 ` [RFC][PATCH 1/3] locking/qspinlock: Re-order code Peter Zijlstra
2018-10-01 17:17 ` Will Deacon
2018-09-26 11:01 ` [RFC][PATCH 2/3] locking/qspinlock: Rework some comments Peter Zijlstra
2018-10-01 17:17 ` Will Deacon
2018-10-01 19:10 ` Peter Zijlstra
2018-10-02 13:20 ` Will Deacon
2018-10-02 13:43 ` Peter Zijlstra [this message]
2018-09-26 11:01 ` [RFC][PATCH 3/3] locking/qspinlock: Optimize for x86 Peter Zijlstra
2018-09-26 16:30 ` Waiman Long
2018-09-26 17:54 ` Peter Zijlstra
2018-09-27 7:29 ` Peter Zijlstra
2018-09-26 20:52 ` Andrea Parri
2018-09-27 7:17 ` Peter Zijlstra
2018-09-27 7:47 ` Andrea Parri
2018-09-27 7:59 ` Peter Zijlstra
2018-09-27 8:13 ` Andrea Parri
2018-09-27 8:57 ` Peter Zijlstra
2018-09-27 12:16 ` David Laight
2018-10-01 17:17 ` Will Deacon
2018-10-01 20:00 ` Peter Zijlstra
2018-10-02 13:19 ` Will Deacon
2018-10-02 14:14 ` Peter Zijlstra
2018-10-02 12:31 ` Andrea Parri
2018-10-02 13:22 ` Will Deacon
2018-10-02 13:44 ` Andrea Parri
2018-09-26 15:01 ` [RFC][PATCH 0/3] locking/qspinlock: Improve determinism " Sebastian Andrzej Siewior
2018-09-26 15:08 ` Thomas Gleixner
2018-09-26 15:38 ` Sebastian Andrzej Siewior
2018-09-26 16:20 ` Waiman Long
2018-09-26 17:51 ` Peter Zijlstra
2018-09-26 23:21 ` Waiman Long
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=20181002134358.GD26858@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrea.parri@amarulasolutions.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.