From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, will.deacon@arm.com,
peterz@infradead.org, schwidefsky@de.ibm.com,
paulmck@linux.vnet.ibm.com, gang.chen@asianux.com,
heiko.carstens@de.ibm.com, tglx@linutronix.de
Cc: tipbot@zytor.com, linux-tip-commits@vger.kernel.org
Subject: Re: [tip:locking/core] arch,s390: Convert smp_mb__*()
Date: Wed, 23 Apr 2014 09:37:57 +0200 [thread overview]
Message-ID: <20140423093757.2c07c209@mschwide> (raw)
In-Reply-To: <tip-kme5dz5hcobpnufnnkh1ech2@git.kernel.org>
Hi Peter,
On Fri, 18 Apr 2014 06:11:38 -0700
tip-bot for Peter Zijlstra <tipbot@zytor.com> wrote:
> arch,s390: Convert smp_mb__*()
>
> As per the existing implementation; implement the new one using
> smp_mb().
>
> AFAICT the s390 compare-and-swap does imply a barrier, however there
> are some immediate ops that seem to be singly-copy atomic and do not
> imply a barrier. One such is the "ni" op (which would be
> and-immediate) which is used for the constant clear_bit
> implementation. Therefore s390 needs full barriers for the
> {before,after} atomic ops.
Good catch, if ni/oi are used this is required. What we want to
add is an #ifdef CONFIG_HAVE_MARCH_Z196_FEATURES. With smp_mb__*
defined as smp_mb() we get additional barriers for older machines
while the atomic ops are defined with compare-and-swap which
already does the barrier before and after the operation.
We can do that with a patch on top of this one, so no hurry.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
prev parent reply other threads:[~2014-04-23 7:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-18 13:11 [tip:locking/core] arch,s390: Convert smp_mb__*() tip-bot for Peter Zijlstra
2014-04-23 7:37 ` Martin Schwidefsky [this message]
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=20140423093757.2c07c209@mschwide \
--to=schwidefsky@de.ibm.com \
--cc=gang.chen@asianux.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tipbot@zytor.com \
--cc=torvalds@linux-foundation.org \
--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.