On Wed, Oct 07, 2020 at 11:07:17PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2020 at 10:11:07AM -0700, Paul E. McKenney wrote:
>
> > Challenges include:
> >
> > o Unmarked accesses. Compilers are quite aggressive about
> > moving normal code.
>
> Which is why this thread exists :-)
On Wed, Oct 07, 2020 at 10:11:07AM -0700, Paul E. McKenney wrote:
> Challenges include:
>
> o Unmarked accesses. Compilers are quite aggressive about
> moving normal code.
Which is why this thread exists :-) We wants to dis-allow lifting the
stores over our volatile-if.
> o
On Wed, Oct 07, 2020 at 01:50:54PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 07, 2020 at 12:20:41PM +0200, Florian Weimer wrote:
> > * Peter Zijlstra:
[ . . . ]
> > >> I think in GCC, they are called __atomic_load_n(foo, __ATOMIC_RELAXED)
> > >> and __atomic_store_n(foo, __ATOMIC_RELAXED). GCC
On Wed, Oct 07, 2020 at 12:20:41PM +0200, Florian Weimer wrote:
> * Peter Zijlstra:
> > A branch that cannot be optimized away and prohibits lifting stores
> > over. One possible suggestion would be allowing the volatile keyword as
> > a qualifier to if.
> >
> > x = *foo;
> > volatile if
On Wed, Oct 07, 2020 at 11:32:43AM +0200, Peter Zijlstra wrote:
> A branch that cannot be optimized away and prohibits lifting stores
> over. One possible suggestion would be allowing the volatile keyword as
> a qualifier to if.
>
> x = *foo;
> volatile if (x > 42)
>
* Peter Zijlstra:
> On Tue, Oct 06, 2020 at 11:20:01PM +0200, Florian Weimer wrote:
>> * Peter Zijlstra:
>>
>> > Our Documentation/memory-barriers.txt has a Control Dependencies section
>> > (which I shall not replicate here for brevity) which lists a number of
>> > caveats. But in general the
On Tue, Oct 06, 2020 at 11:20:01PM +0200, Florian Weimer wrote:
> * Peter Zijlstra:
>
> > Our Documentation/memory-barriers.txt has a Control Dependencies section
> > (which I shall not replicate here for brevity) which lists a number of
> > caveats. But in general the work-around we use is:
> >
* Peter Zijlstra:
> Our Documentation/memory-barriers.txt has a Control Dependencies section
> (which I shall not replicate here for brevity) which lists a number of
> caveats. But in general the work-around we use is:
>
> x = READ_ONCE(*foo);
> if (x > 42)
>
On Tue, Oct 06, 2020 at 04:22:10PM +, David Laight wrote:
> From: Willy Tarreau
> > Sent: 06 October 2020 17:11
> >
> > On Tue, Oct 06, 2020 at 08:50:52AM -0700, Paul E. McKenney wrote:
> > > Comparing 25+ assembly languages to but two compilers most definitely
> > > motivates looking hard at
From: Willy Tarreau
> Sent: 06 October 2020 17:11
>
> On Tue, Oct 06, 2020 at 08:50:52AM -0700, Paul E. McKenney wrote:
> > Comparing 25+ assembly languages to but two compilers most definitely
> > motivates looking hard at doing something with the compilers.
>
> +1, especially since the kernel
On Tue, Oct 06, 2020 at 08:50:52AM -0700, Paul E. McKenney wrote:
> Comparing 25+ assembly languages to but two compilers most definitely
> motivates looking hard at doing something with the compilers.
+1, especially since the kernel is not special; anyone working with
threads faces the same
On Tue, Oct 06, 2020 at 03:37:24PM +, David Laight wrote:
> > My suggestion as an alternative is to use assembler instead.
> > That way you can guarantee that you get the instructions you
> > want in the order that you want them. It should be fairly
> > straightforward to create a
> My suggestion as an alternative is to use assembler instead.
> That way you can guarantee that you get the instructions you
> want in the order that you want them. It should be fairly
> straightforward to create a macro or inline function that
> contains the necessary code and this
Hi Guys,
OK, so playing the devils advocate here...
> Mostly I just want the compiler people to say they'll guarantee the
> behaviour if we do 'X'. If 'X' happens to be 'any dynamic branch headed
> by a volatile load' that's fine by me.
Is a compiler hack really the right way to go here ?
> Please go read memory-barriers.txt for a bunch of other examples.
My brain hurts.
It's not as though I've not known about most of this since
the first SMP capable SPARC cpus that had a 'store buffer'.
(Probably 30 years ago.)
I sometimes wonder whether compiling things like the kernel
requires
On Tue, Oct 06, 2020 at 10:23:24AM -0400, st...@rowland.harvard.edu wrote:
> On Tue, Oct 06, 2020 at 03:31:15PM +0200, Peter Zijlstra wrote:
> > Only if we get the compiler people on board and have them provide means
> > are we guaranteed safe from the optimizer. Otherwise we'll just keep
> >
On Tue, Oct 06, 2020 at 03:31:15PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 06, 2020 at 12:37:06PM +, David Laight wrote:
> > From: Peter Zijlstra
> > > Sent: 06 October 2020 12:47
> > > Hi,
> > >
> > > Let's give this linux-toolchains thing a test-run...
> > >
> > > As some of you might
On Tue, Oct 06, 2020 at 12:37:06PM +, David Laight wrote:
> From: Peter Zijlstra
> > Sent: 06 October 2020 12:47
> > Hi,
> >
> > Let's give this linux-toolchains thing a test-run...
> >
> > As some of you might know, there's a bit of a discrepancy between what
> > compiler and kernel people
On Tue, Oct 06, 2020 at 12:37:06PM +, David Laight wrote:
> > Our Documentation/memory-barriers.txt has a Control Dependencies section
> > (which I shall not replicate here for brevity) which lists a number of
> > caveats. But in general the work-around we use is:
> >
> > x =
From: Peter Zijlstra
> Sent: 06 October 2020 12:47
> Hi,
>
> Let's give this linux-toolchains thing a test-run...
>
> As some of you might know, there's a bit of a discrepancy between what
> compiler and kernel people consider 'valid' use of the compiler :-)
>
> One area where this shows up is
20 matches
Mail list logo
