On Sat, Sep 05, 2015 at 06:53:02PM +0100, Peter Zijlstra wrote:
> On Wed, Sep 02, 2015 at 02:18:53PM -0700, Linus Torvalds wrote:
> > So I think we could possibly relax the requirements (and document this
> > very clearly) to say that the futex operation must be totally ordered
> > wrt any other _u
On Wed, Sep 02, 2015 at 02:18:53PM -0700, Linus Torvalds wrote:
> So I think we could possibly relax the requirements (and document this
> very clearly) to say that the futex operation must be totally ordered
> wrt any other _user_space_ accesses by that thread. I suspect a lot of
> architectures c
On 09/02/2015 05:18 PM, Linus Torvalds wrote:
For example, on x86, the locked instructions are obviously already
sufficiently strong, but even if they weren't, kernel entry/exit is
documented to be a serializing instruction (which is something
insanely much stronger than just memory ordering). An
On Wed, Sep 2, 2015 at 10:00 AM, Peter Zijlstra wrote:
>
> So I'm reading that code like:
>
> MB
> [RmW] ret = *val += i
>
>
> So what is stopping later memory ops like:
>
>[R] a = *foo
>[S] *bar = b
>
> From getting reordered with the RmW, like:
>
> MB
>
>[R] a =
On 09/02/2015 01:00 PM, Peter Zijlstra wrote:
On Wed, Sep 02, 2015 at 12:10:58PM -0400, Chris Metcalf wrote:
On 09/02/2015 08:55 AM, Peter Zijlstra wrote:
So here goes..
Chris, I'm awfully sorry, but I seem to be Tile challenged.
TileGX seems to define:
#define smp_mb__before_atomic() smp_mb
On Wed, Sep 02, 2015 at 12:10:58PM -0400, Chris Metcalf wrote:
> On 09/02/2015 08:55 AM, Peter Zijlstra wrote:
> >So here goes..
> >
> >Chris, I'm awfully sorry, but I seem to be Tile challenged.
> >
> >TileGX seems to define:
> >
> >#define smp_mb__before_atomic() smp_mb()
> >#define smp_mb__
On 09/02/2015 08:55 AM, Peter Zijlstra wrote:
So here goes..
Chris, I'm awfully sorry, but I seem to be Tile challenged.
TileGX seems to define:
#define smp_mb__before_atomic() smp_mb()
#define smp_mb__after_atomic() smp_mb()
However, its atomic_add_return() implementation looks like:
stati
So here goes..
Chris, I'm awfully sorry, but I seem to be Tile challenged.
TileGX seems to define:
#define smp_mb__before_atomic() smp_mb()
#define smp_mb__after_atomic() smp_mb()
However, its atomic_add_return() implementation looks like:
static inline int atomic_add_return(int i, atomic_t
On Tue, 1 Sep 2015, Peter Zijlstra wrote:
> On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote:
> > Hi Peter,
> >
> > On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote:
> > > I tried to keep this email short, but failed miserably at this. For
> > > the TL;DR skip to the tail.
On Tue, Sep 01, 2015 at 05:42:47PM +0100, Peter Zijlstra wrote:
> On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote:
> > On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote:
> > > I tried to keep this email short, but failed miserably at this. For
> > > the TL;DR skip to the ta
On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote:
> Hi Peter,
>
> On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote:
> > I tried to keep this email short, but failed miserably at this. For
> > the TL;DR skip to the tail.
>
> [...]
>
> > There are a few options:
> >
> >
On Fri, Aug 28, 2015 at 06:33:06PM -0700, Davidlohr Bueso wrote:
> On Wed, 2015-08-26 at 20:16 +0200, Peter Zijlstra wrote:
> > Of course, if anything else prior to futex_atomic_op_inuser() implies an
> > (RCsc) RELEASE or stronger the primitive can do without providing
> > anything itself.
> >
>
Hi Peter,
On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote:
> I tried to keep this email short, but failed miserably at this. For
> the TL;DR skip to the tail.
[...]
> There are a few options:
>
> 1) punt, mandate they're both fully ordered and stop thinking about it
>
> 2) mak
On Wed, 2015-08-26 at 20:16 +0200, Peter Zijlstra wrote:
> Of course, if anything else prior to futex_atomic_op_inuser() implies an
> (RCsc) RELEASE or stronger the primitive can do without providing
> anything itself.
>
> This turns out to be the case, a successful get_futex_key() implies a
> ful
Hi all,
I tried to keep this email short, but failed miserably at this. For
the TL;DR skip to the tail.
So the question of ordering constraints of futex atomic operations has
come up recently:
http://marc.info/?l=linux-kernel&m=143894765931868
This email will attempt to describe the two primi
15 matches
Mail list logo
