From: Peter Zijlstra <peterz@infradead.org>
To: Petros Koutoupis <petros@petroskoutoupis.com>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>,
linux-kernel@vger.kernel.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Davidlohr Bueso <dave@stgolabs.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
catalin.marinas@arm.com, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: futex: clarification needed with drop_futex_key_refs and memory barriers
Date: Thu, 31 Mar 2016 09:36:42 +0200 [thread overview]
Message-ID: <20160331073642.GE3408@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1459388710.4600.7.camel@petros-ultrathin>
On Wed, Mar 30, 2016 at 08:45:10PM -0500, Petros Koutoupis wrote:
> > But this is not a correctness (nor ordering) issue; but purely an
> > architectural side-effect. Furthermore; some proposed changes:
> >
> > http://marc.info/?l=linux-kernel&m=145400059704564&w=2
> >
> > might change this side-effect.
> >
>
> Has there been an update to this patch? The last I see, the conversation
> ended at the end of January, and there hasn't been a change in the
> mainline.
Peter Anvin was going to look at this with some of the Intel hardware
people to fully explore the ramifications of this change, we're waiting
on feedback from that.
> >> Your adjustments here make complete sense. Are you preparing it for
> submission in the near future?
I'll think about it, adding the extra barrier for decrement is of course
not really nice if not strictly required. And while it will not impact
x86 the weakly ordered archs will be affected.
next prev parent reply other threads:[~2016-03-31 7:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-26 15:56 futex: clarification needed with drop_futex_key_refs and memory barriers Petros Koutoupis
2016-03-27 6:25 ` Mike Galbraith
2016-03-29 9:50 ` Peter Zijlstra
2016-03-31 1:45 ` Petros Koutoupis
2016-03-31 7:36 ` Peter Zijlstra [this message]
2016-04-02 6:39 ` Davidlohr Bueso
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=20160331073642.GE3408@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=catalin.marinas@arm.com \
--cc=dave@stgolabs.net \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=petros@petroskoutoupis.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=umgwanakikbuti@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox