On Thu, Jun 18, 2015 at 01:10:22PM -0400, Steven Rostedt wrote:
> On Thu, 18 Jun 2015 09:54:07 -0700
> "Paul E. McKenney" wrote:
>
> > Yep, I have to frequently remind them that most projects need to support
> > old compilers. And I did point out that the commentary at the end
> > of that
On Thu, 18 Jun 2015 09:54:07 -0700
"Paul E. McKenney" wrote:
> Yep, I have to frequently remind them that most projects need to support
> old compilers. And I did point out that the commentary at the end
> of that document would not encourage adoption of C11. They of course
> felt this was
On Thu, Jun 18, 2015 at 12:40:15PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote:
>
> > In what retarded use-case do unasked for speculative writes even make any
> > sense
> > beyond as a sadistic tool to make parallel, threaded code even more
> >
On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote:
> In what retarded use-case do unasked for speculative writes even make any
> sense
> beyond as a sadistic tool to make parallel, threaded code even more fragile??
So what worries me most is the "Takeaways" from the document:
* Peter Zijlstra wrote:
> > > I doubt there's a single OS kernel (that supports SMP configurations)
> > > that
> > > does not rely on a whole host of 'undefined' behaviour.
> >
> > An alternative approach would be a compiler switch (or similar) that
> > changed
> > the default atomic
On Wed, Jun 17, 2015 at 11:02:14AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 17, 2015 at 07:11:40PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 17, 2015 at 09:37:31AM -0700, Paul E. McKenney wrote:
> > > The point of std::atomic<> (and of the equivalent C11 syntax) is to
> > > force the
On Thu, Jun 18, 2015 at 12:40:15PM +0200, Peter Zijlstra wrote:
On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote:
In what retarded use-case do unasked for speculative writes even make any
sense
beyond as a sadistic tool to make parallel, threaded code even more
fragile??
On Thu, 18 Jun 2015 09:54:07 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Yep, I have to frequently remind them that most projects need to support
old compilers. And I did point out that the commentary at the end
of that document would not encourage adoption of C11. They of
On Thu, Jun 18, 2015 at 01:10:22PM -0400, Steven Rostedt wrote:
On Thu, 18 Jun 2015 09:54:07 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Yep, I have to frequently remind them that most projects need to support
old compilers. And I did point out that the commentary at the end
On Wed, Jun 17, 2015 at 11:02:14AM -0700, Paul E. McKenney wrote:
On Wed, Jun 17, 2015 at 07:11:40PM +0200, Peter Zijlstra wrote:
On Wed, Jun 17, 2015 at 09:37:31AM -0700, Paul E. McKenney wrote:
The point of std::atomic (and of the equivalent C11 syntax) is to
force the compiler to
* Peter Zijlstra pet...@infradead.org wrote:
I doubt there's a single OS kernel (that supports SMP configurations)
that
does not rely on a whole host of 'undefined' behaviour.
An alternative approach would be a compiler switch (or similar) that
changed
the default atomic
On Thu, Jun 18, 2015 at 11:40:14AM +0200, Ingo Molnar wrote:
In what retarded use-case do unasked for speculative writes even make any
sense
beyond as a sadistic tool to make parallel, threaded code even more fragile??
So what worries me most is the Takeaways from the document:
On Wed, Jun 17, 2015 at 07:11:40PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 17, 2015 at 09:37:31AM -0700, Paul E. McKenney wrote:
> > The point of std::atomic<> (and of the equivalent C11 syntax) is to
> > force the compiler to suppress optimizations that are unsafe for shared
> > variables. We
On Wed, Jun 17, 2015 at 09:37:31AM -0700, Paul E. McKenney wrote:
> The point of std::atomic<> (and of the equivalent C11 syntax) is to
> force the compiler to suppress optimizations that are unsafe for shared
> variables. We get more or less the same effect with volatile, protests
> from
On Wed, Jun 17, 2015 at 08:42:45AM -0700, Paul E. McKenney wrote:
> > I would very much prefer a compiler switch that instructs the compiler
> > to not do bloody stupid things like this instead of marking every other
> > load/store in the kernel with volatile.
>
> I would of course be good with
On Wed, Jun 17, 2015 at 05:49:27PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
> > > I did leave off the READ/WRITE ONCE stuff, because I could not come up
> > > with a scenario
On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
> > I did leave off the READ/WRITE ONCE stuff, because I could not come up
> > with a scenario where it makes a difference -- I appreciate paranoia,
> > but I also
On Wed, Jun 17, 2015 at 05:11:09PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
> > > I did leave off the READ/WRITE ONCE stuff, because I could not come up
> > > with a scenario
On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
> > I did leave off the READ/WRITE ONCE stuff, because I could not come up
> > with a scenario where it makes a difference -- I appreciate paranoia,
> > but I also
On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
> > Color me slow and stupid. Maybe due to reviewing a patch too early in
> > the morning, who knows?
> >
> > There is nothing above that prevents the compiler and
On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
> Color me slow and stupid. Maybe due to reviewing a patch too early in
> the morning, who knows?
>
> There is nothing above that prevents the compiler and the CPU from
> reordering the assignments to X and Y with the increment of
On Wed, Jun 17, 2015 at 07:11:40PM +0200, Peter Zijlstra wrote:
On Wed, Jun 17, 2015 at 09:37:31AM -0700, Paul E. McKenney wrote:
The point of std::atomic (and of the equivalent C11 syntax) is to
force the compiler to suppress optimizations that are unsafe for shared
variables. We get more
On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
Color me slow and stupid. Maybe due to reviewing a patch too early in
the morning, who knows?
There is nothing above that prevents the compiler and the CPU from
reordering the assignments to X and Y with the increment of
On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
Color me slow and stupid. Maybe due to reviewing a patch too early in
the morning, who knows?
There is nothing above that prevents the compiler and the CPU
On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
I did leave off the READ/WRITE ONCE stuff, because I could not come up
with a scenario where it makes a difference -- I appreciate paranoia,
but I also think we
On Wed, Jun 17, 2015 at 05:11:09PM +0200, Peter Zijlstra wrote:
On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
I did leave off the READ/WRITE ONCE stuff, because I could not come up
with a scenario where it
On Wed, Jun 17, 2015 at 08:42:45AM -0700, Paul E. McKenney wrote:
I would very much prefer a compiler switch that instructs the compiler
to not do bloody stupid things like this instead of marking every other
load/store in the kernel with volatile.
I would of course be good with such a
On Wed, Jun 17, 2015 at 09:37:31AM -0700, Paul E. McKenney wrote:
The point of std::atomic (and of the equivalent C11 syntax) is to
force the compiler to suppress optimizations that are unsafe for shared
variables. We get more or less the same effect with volatile, protests
from compiler
On Wed, Jun 17, 2015 at 05:49:27PM +0200, Peter Zijlstra wrote:
On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
I did leave off the READ/WRITE ONCE stuff, because I could not come up
with a scenario where it
On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote:
On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote:
I did leave off the READ/WRITE ONCE stuff, because I could not come up
with a scenario where it makes a difference -- I appreciate paranoia,
but I also think we
On 06/11, Paul E. McKenney wrote:
>
> > > + * seqcount_t seq;
> > > + * bool X = true, Y = false;
> > > + *
> > > + * void read(void)
> > > + * {
> > > + * bool x, y;
> > > + *
> > > + * do {
> > > + * int s =
On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
> Color me slow and stupid. Maybe due to reviewing a patch too early in
> the morning, who knows?
>
> There is nothing above that prevents the compiler and the CPU from
> reordering the assignments to X and Y with the increment of
On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
Color me slow and stupid. Maybe due to reviewing a patch too early in
the morning, who knows?
There is nothing above that prevents the compiler and the CPU from
reordering the assignments to X and Y with the increment of
On 06/11, Paul E. McKenney wrote:
+ * seqcount_t seq;
+ * bool X = true, Y = false;
+ *
+ * void read(void)
+ * {
+ * bool x, y;
+ *
+ * do {
+ * int s = read_seqcount_begin(seq);
+ *
+ *
On Thu, Jun 11, 2015 at 08:33:41AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 11, 2015 at 02:46:47PM +0200, Peter Zijlstra wrote:
> > Introduce raw_write_seqcount_barrier(), a new construct that can be
> > used to provide write barrier semantics in seqcount read loops instead
> > of the usual
On Thu, Jun 11, 2015 at 02:46:47PM +0200, Peter Zijlstra wrote:
> Introduce raw_write_seqcount_barrier(), a new construct that can be
> used to provide write barrier semantics in seqcount read loops instead
> of the usual consistency guarantee.
>
> Cc: Al Viro
> Cc: Linus Torvalds
> Cc: Paul
Introduce raw_write_seqcount_barrier(), a new construct that can be
used to provide write barrier semantics in seqcount read loops instead
of the usual consistency guarantee.
Cc: Al Viro
Cc: Linus Torvalds
Cc: Paul McKenney
Suggested-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra (Intel)
Introduce raw_write_seqcount_barrier(), a new construct that can be
used to provide write barrier semantics in seqcount read loops instead
of the usual consistency guarantee.
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Paul McKenney
On Thu, Jun 11, 2015 at 08:33:41AM -0700, Paul E. McKenney wrote:
On Thu, Jun 11, 2015 at 02:46:47PM +0200, Peter Zijlstra wrote:
Introduce raw_write_seqcount_barrier(), a new construct that can be
used to provide write barrier semantics in seqcount read loops instead
of the usual
On Thu, Jun 11, 2015 at 02:46:47PM +0200, Peter Zijlstra wrote:
Introduce raw_write_seqcount_barrier(), a new construct that can be
used to provide write barrier semantics in seqcount read loops instead
of the usual consistency guarantee.
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Linus
40 matches
Mail list logo
