On 18 February 2014 17:16, Paul E. McKenney [off-list ref] wrote:

On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote:

quoted

On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel [off-list ref] wrote:

quoted

On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:

quoted

And exactly because I know enough, I would *really* like atomics to be
well-defined, and have very clear - and *local* - rules about how they
can be combined and optimized.

"Local"?

Yes.

So I think that one of the big advantages of atomics over volatile is
that they *can* be optimized, and as such I'm not at all against
trying to generate much better code than for volatile accesses.

But at the same time, that can go too far. For example, one of the
things we'd want to use atomics for is page table accesses, where it
is very important that we don't generate multiple accesses to the
values, because parts of the values can be change *by*hardware* (ie
accessed and dirty bits).

So imagine that you have some clever global optimizer that sees that
the program never ever actually sets the dirty bit at all in any
thread, and then uses that kind of non-local knowledge to make
optimization decisions. THAT WOULD BE BAD.

Might as well list other reasons why value proofs via whole-program
analysis are unreliable for the Linux kernel:

1.      As Linus said, changes from hardware.

2.      Assembly code that is not visible to the compiler.
        Inline asms will -normally- let the compiler know what
        memory they change, but some just use the "memory" tag.
        Worse yet, I suspect that most compilers don't look all
        that carefully at .S files.

        Any number of other programs contain assembly files.

3.      Kernel modules that have not yet been written.  Now, the
        compiler could refrain from trying to prove anything about
        an EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() variable, but there
        is currently no way to communicate this information to the
        compiler other than marking the variable "volatile".

        Other programs have similar issues, e.g., via dlopen().

4.      Some drivers allow user-mode code to mmap() some of their
        state.  Any changes undertaken by the user-mode code would
        be invisible to the compiler.

5.      JITed code produced based on BPF: https://lwn.net/Articles/437981/

And probably other stuff as well.

interesting list.  So are you saying that value-range-analysis and
such-like (I say glibly, without really knowing what "such-like"
refers to here) are fundamentally incompatible with
the kernel code, or can you think of some way to tell the compiler a
bound on the footprint of the "unseen" changes in each of those cases?

Peter

                                                        Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/