[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c0cb8a2-eba2-7bea-8523-b948253a6804@arm.com>
Date: Fri, 16 Aug 2019 23:27:46 +0100
From: Valentin Schneider <valentin.schneider@....com>
To: Joel Fernandes <joel@...lfernandes.org>,
Thomas Gleixner <tglx@...utronix.de>
Cc: Alan Stern <stern@...land.harvard.edu>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
rostedt <rostedt@...dmis.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
paulmck <paulmck@...ux.ibm.com>,
Boqun Feng <boqun.feng@...il.com>,
Will Deacon <will.deacon@....com>,
David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 1/1] Fix: trace sched switch start/stop racy updates
On 16/08/2019 21:57, Joel Fernandes wrote:
>> Can we finally put a foot down and tell compiler and standard committee
>> people to stop this insanity?
>
> Sure, or could the compilers provide flags which prevent such optimization
> similar to -O* flags?
>
How would you differentiate optimizations you want from those you don't with
just a flag? There's a reason we use volatile casts instead of declaring
everything volatile: we actually *want* those optimizations. It just so
happens that we don't want them *in some places*, and we have tools to tag
them as such.
The alternative is having a compiler that can magically correlate e.g. locked
writes with lock-free reads and properly handle them, but I don't think
there's a foolproof way of doing that.
> thanks,
>
> - Joel
>
Powered by blists - more mailing lists