On Mon, Sep 30, 2019 at 01:54:40PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 30, 2019 at 11:33:52AM +0200, Peter Zijlstra wrote:
> > Like I said before, something like: "disallowing store hoists over control
> > flow depending on a volatile load" would be sufficient I think.
>
> We need to add 'c
On Mon, Sep 30, 2019 at 11:33:52AM +0200, Peter Zijlstra wrote:
> Like I said before, something like: "disallowing store hoists over control
> flow depending on a volatile load" would be sufficient I think.
We need to add 'control flow depending on an inline-asm' to that. We
also very much use tha
On Fri, Sep 27, 2019 at 01:43:18PM -0700, Nick Desaulniers wrote:
> On Fri, Sep 27, 2019 at 5:49 AM Peter Zijlstra wrote:
> Oh, in that case I'm less sure (I still don't think so, but I would
> love to be proven wrong, preferably with a godbolt link). I think the
> best would be to share a godbo
On Fri, Sep 27, 2019 at 1:43 PM Nick Desaulniers
wrote:
>
> On Fri, Sep 27, 2019 at 5:49 AM Peter Zijlstra wrote:
> > Barring LTO the above works for perf because of inter-translation-unit
> > function calls, which imply a compiler barrier.
> >
> > Now, when the compiler inlines, it looses that s
On Fri, Sep 27, 2019 at 5:49 AM Peter Zijlstra wrote:
>
> On Fri, Sep 27, 2019 at 11:51:07AM +0200, Andrea Parri wrote:
>
> > For the record, the LKMM doesn't currently model "order" derived from
> > control dependencies to a _plain_ access (even if the plain access is
> > a write): in particular,
On Fri, Sep 27, 2019 at 02:49:29PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 27, 2019 at 11:51:07AM +0200, Andrea Parri wrote:
>
> > For the record, the LKMM doesn't currently model "order" derived from
> > control dependencies to a _plain_ access (even if the plain access is
> > a write): in par
On Fri, Sep 27, 2019 at 11:51:07AM +0200, Andrea Parri wrote:
> For the record, the LKMM doesn't currently model "order" derived from
> control dependencies to a _plain_ access (even if the plain access is
> a write): in particular, the following is racy (as far as the current
> LKMM is concerned)
On Mon, Sep 23, 2019 at 04:49:31PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 19, 2019 at 02:59:06PM +0100, David Howells wrote:
>
> > But I don't agree with this. You're missing half the barriers. There
> > should
> > be *four* barriers. The document mandates only 3 barriers, and uses
> > REA
On Thu, Sep 19, 2019 at 02:59:06PM +0100, David Howells wrote:
> But I don't agree with this. You're missing half the barriers. There should
> be *four* barriers. The document mandates only 3 barriers, and uses
> READ_ONCE() where the fourth should be, i.e.:
>
>thread #1thread
On Thu, Sep 19, 2019 at 6:59 AM David Howells wrote:
>
> But I don't agree with this. You're missing half the barriers. There should
> be *four* barriers. The document mandates only 3 barriers, and uses
> READ_ONCE() where the fourth should be, i.e.:
>
>thread #1thread #2
>
>
Linus Torvalds wrote:
> > It mandates using smp_store_release() to update buffer->head in the producer
> > and buffer->tail in the consumer - but these need pairing with memory
> > barriers
> > used when reading buffer->head and buffer->tail on the other side.
>
> No, the rule with smp_store_rel
On Wed, Sep 18, 2019 at 8:43 AM David Howells wrote:
>
> It mandates using smp_store_release() to update buffer->head in the producer
> and buffer->tail in the consumer - but these need pairing with memory barriers
> used when reading buffer->head and buffer->tail on the other side.
No, the rule
Will Deacon wrote:
> If I'm understanding your code correctly (big 'if'), then you have things
> like this in pipe_read():
>
>
> unsigned int head = READ_ONCE(pipe->head);
> unsigned int tail = pipe->tail;
> unsigned int mask = pipe->buffers - 1;
>
> if (tail != head) {
13 matches
Mail list logo
