From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Torvald Riegel <triegel@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
David Howells <dhowells@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-kernel@vger.kernel.org"
<linux-kernel@vger.kernel.org>,
"torvalds@linux-foundation.org"
<torvalds@linux-foundation.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mingo@kernel.org" <mingo@kernel.org>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
Date: Thu, 06 Feb 2014 21:55:00 -0000 [thread overview]
Message-ID: <20140206215521.GI4250@linux.vnet.ibm.com> (raw)
In-Reply-To: <1391720965.23421.3884.camel@triegel.csb>
On Thu, Feb 06, 2014 at 10:09:25PM +0100, Torvald Riegel wrote:
> On Thu, 2014-02-06 at 18:59 +0000, Will Deacon wrote:
> > On Thu, Feb 06, 2014 at 06:55:01PM +0000, Ramana Radhakrishnan wrote:
> > > On 02/06/14 18:25, David Howells wrote:
> > > >
> > > > Is it worth considering a move towards using C11 atomics and barriers and
> > > > compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
> > > > these.
> > >
> > >
> > > It sounds interesting to me, if we can make it work properly and
> > > reliably. + gcc@gcc.gnu.org for others in the GCC community to chip in.
> >
> > Given my (albeit limited) experience playing with the C11 spec and GCC, I
> > really think this is a bad idea for the kernel.
>
> I'm not going to comment on what's best for the kernel (simply because I
> don't work on it), but I disagree with several of your statements.
>
> > It seems that nobody really
> > agrees on exactly how the C11 atomics map to real architectural
> > instructions on anything but the trivial architectures.
>
> There's certainly different ways to implement the memory model and those
> have to be specified elsewhere, but I don't see how this differs much
> from other things specified in the ABI(s) for each architecture.
>
> > For example, should
> > the following code fire the assert?
>
> I don't see how your example (which is about what the language requires
> or not) relates to the statement about the mapping above?
>
> >
> > extern atomic<int> foo, bar, baz;
> >
> > void thread1(void)
> > {
> > foo.store(42, memory_order_relaxed);
> > bar.fetch_add(1, memory_order_seq_cst);
> > baz.store(42, memory_order_relaxed);
> > }
> >
> > void thread2(void)
> > {
> > while (baz.load(memory_order_seq_cst) != 42) {
> > /* do nothing */
> > }
> >
> > assert(foo.load(memory_order_seq_cst) == 42);
> > }
> >
>
> It's a good example. My first gut feeling was that the assertion should
> never fire, but that was wrong because (as I seem to usually forget) the
> seq-cst total order is just a constraint but doesn't itself contribute
> to synchronizes-with -- but this is different for seq-cst fences.
From what I can see, Will's point is that mapping the Linux kernel's
atomic_add_return() primitive into fetch_add() does not work because
atomic_add_return()'s ordering properties require that the assert()
never fire.
Augmenting the fetch_add() with a seq_cst fence would work on many
architectures, but not for all similar examples. The reason is that
the C11 seq_cst fence is deliberately weak compared to ARM's dmb or
Power's sync. To your point, I believe that it would make the above
example work, but there are some IRIW-like examples that would fail
according to the standard (though a number of specific implementations
would in fact work correctly).
> > To answer that question, you need to go and look at the definitions of
> > synchronises-with, happens-before, dependency_ordered_before and a whole
> > pile of vaguely written waffle to realise that you don't know.
>
> Are you familiar with the formalization of the C11/C++11 model by Batty
> et al.?
> http://www.cl.cam.ac.uk/~mjb220/popl085ap-sewell.pdf
> http://www.cl.cam.ac.uk/~mjb220/n3132.pdf
>
> They also have a nice tool that can run condensed examples and show you
> all allowed (and forbidden) executions (it runs in the browser, so is
> slow for larger examples), including nice annotated graphs for those:
> http://svr-pes20-cppmem.cl.cam.ac.uk/cppmem/
>
> It requires somewhat special syntax, but the following, which should be
> equivalent to your example above, runs just fine:
>
> int main() {
> atomic_int foo = 0;
> atomic_int bar = 0;
> atomic_int baz = 0;
> {{{ {
> foo.store(42, memory_order_relaxed);
> bar.store(1, memory_order_seq_cst);
> baz.store(42, memory_order_relaxed);
> }
> ||| {
> r1=baz.load(memory_order_seq_cst).readsvalue(42);
> r2=foo.load(memory_order_seq_cst).readsvalue(0);
> }
> }}};
> return 0; }
>
> That yields 3 consistent executions for me, and likewise if the last
> readsvalue() is using 42 as argument.
>
> If you add a "fence(memory_order_seq_cst);" after the store to foo, the
> program can't observe != 42 for foo anymore, because the seq-cst fence
> is adding a synchronizes-with edge via the baz reads-from.
>
> I think this is a really neat tool, and very helpful to answer such
> questions as in your example.
Hmmm... The tool doesn't seem to like fetch_add(). But let's assume that
your substitution of store() for fetch_add() is correct. Then this shows
that we cannot substitute fetch_add() for atomic_add_return().
Adding atomic_thread_fence(memory_order_seq_cst) after the bar.store
gives me "192 executions; no consistent", so perhaps there is hope for
augmenting the fetch_add() with a fence. Except, as noted above, for
any number of IRIW-like examples such as the following:
int main() {
atomic_int x = 0; atomic_int y = 0;
{{{ x.store(1, memory_order_release);
||| y.store(1, memory_order_release);
||| { r1=x.load(memory_order_relaxed).readsvalue(1);
atomic_thread_fence(memory_order_seq_cst);
r2=y.load(memory_order_relaxed).readsvalue(0); }
||| { r3=y.load(memory_order_relaxed).readsvalue(1);
atomic_thread_fence(memory_order_seq_cst);
r4=x.load(memory_order_relaxed).readsvalue(0); }
}}};
return 0; }
Adding a seq_cst store to a new variable z between each pair of reads
seems to choke cppmem:
int main() {
atomic_int x = 0; atomic_int y = 0; atomic_int z = 0
{{{ x.store(1, memory_order_release);
||| y.store(1, memory_order_release);
||| { r1=x.load(memory_order_relaxed).readsvalue(1);
z.store(1, memory_order_seq_cst);
atomic_thread_fence(memory_order_seq_cst);
r2=y.load(memory_order_relaxed).readsvalue(0); }
||| { r3=y.load(memory_order_relaxed).readsvalue(1);
z.store(1, memory_order_seq_cst);
atomic_thread_fence(memory_order_seq_cst);
r4=x.load(memory_order_relaxed).readsvalue(0); }
}}};
return 0; }
Ah, it did eventually finish with "576 executions; 6 consistent, all
race free". So this is an example where C11 has a hard time modeling
the Linux kernel's atomic_add_return(). Therefore, use of C11 atomics
to implement Linux kernel atomic operations requires knowledge of the
underlying architecture and the compiler's implementation, as was noted
earlier in this thread.
> > Certainly,
> > the code that arm64 GCC currently spits out would allow the assertion to fire
> > on some microarchitectures.
> >
> > There are also so many ways to blow your head off it's untrue. For example,
> > cmpxchg takes a separate memory model parameter for failure and success, but
> > then there are restrictions on the sets you can use for each.
>
> That's in there for the architectures without a single-instruction
> CAS/cmpxchg, I believe.
Yep. The Linux kernel currently requires the rough equivalent of
memory_order_seq_cst for both paths, but there is some chance that the
failure-path requirement might be weakened.
> > It's not hard
> > to find well-known memory-ordering experts shouting "Just use
> > memory_model_seq_cst for everything, it's too hard otherwise".
>
> Everyone I've heard saying this meant this as advice to people new to
> synchronization or just dealing infrequently with it. The advice is the
> simple and safe fallback, and I don't think it's meant as an
> acknowledgment that the model itself would be too hard. If the
> language's memory model is supposed to represent weak HW memory models
> to at least some extent, there's only so much you can do in terms of
> keeping it simple. If all architectures had x86-like models, the
> language's model would certainly be simpler... :)
That is said a lot, but there was a recent Linux-kernel example that
turned out to be quite hard to prove for x86. ;-)
> > Then there's
> > the fun of load-consume vs load-acquire (arm64 GCC completely ignores consume
> > atm and optimises all of the data dependencies away)
>
> AFAIK consume memory order was added to model Power/ARM-specific
> behavior. I agree that the way the standard specifies how dependencies
> are to be preserved is kind of vague (as far as I understand it). See
> GCC PR 59448.
This one? http://gcc.gnu.org/ml/gcc-bugs/2013-12/msg01083.html
That does indeed look to match what Will was calling out as a problem.
> > as well as the definition
> > of "data races", which seem to be used as an excuse to miscompile a program
> > at the earliest opportunity.
>
> No. The purpose of this is to *not disallow* every optimization on
> non-synchronizing code. Due to the assumption of data-race-free
> programs, the compiler can assume a sequential code sequence when no
> atomics are involved (and thus, keep applying optimizations for
> sequential code).
>
> Or is there something particular that you dislike about the
> specification of data races?
Cut Will a break, Torvald! ;-)
> > Trying to introduce system concepts (writes to devices, interrupts,
> > non-coherent agents) into this mess is going to be an uphill battle IMHO.
>
> That might very well be true.
>
> OTOH, if you whould need to model this uniformly across different
> architectures (ie, so that there is a intra-kernel-portable abstraction
> for those system concepts), you might as well try doing this by
> extending the C11/C++11 model. Maybe that will not be successful or not
> really a good fit, though, but at least then it's clear why that's the
> case.
I would guess that Linux-kernel use of C11 atomics will be selected or not
on an architecture-specific for the foreseeable future.
> > I'd
> > just rather stick to the semantics we have and the asm volatile barriers.
> >
> > That's not to say I don't there's no room for improvement in what we have
> > in the kernel. Certainly, I'd welcome allowing more relaxed operations on
> > architectures that support them, but it needs to be something that at least
> > the different architecture maintainers can understand how to implement
> > efficiently behind an uncomplicated interface. I don't think that interface is
> > C11.
>
> IMHO, one thing worth considering is that for C/C++, the C11/C++11 is
> the only memory model that has widespread support. So, even though it's
> a fairly weak memory model (unless you go for the "only seq-cst"
> beginners advice) and thus comes with a higher complexity, this model is
> what likely most people will be familiar with over time. Deviating from
> the "standard" model can have valid reasons, but it also has a cost in
> that new contributors are more likely to be familiar with the "standard"
> model.
>
> Note that I won't claim that the C11/C++11 model is perfect -- there are
> a few rough edges there (e.g., the forward progress guarantees are (or
> used to be) a little coarse for my taste), and consume vs. dependencies
> worries me as well. But, IMHO, overall it's the best C/C++ language
> model we have.
I could be wrong, but I strongly suspect that in the near term,
any memory-model migration of the 15M+ LoC Linux-kernel code base
will be incremental in nature. Especially if the C/C++ committee
insists on strengthening memory_order_relaxed. :-/
Thanx, Paul
next prev parent reply other threads:[~2014-02-06 21:55 UTC|newest]
Thread overview: 279+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140206134825.305510953@infradead.org>
[not found] ` <21984.1391711149@warthog.procyon.org.uk>
2014-02-06 18:55 ` Ramana Radhakrishnan
2014-02-06 18:59 ` Will Deacon
2014-02-06 19:27 ` Paul E. McKenney
2014-02-06 21:17 ` Torvald Riegel
2014-02-06 22:11 ` Paul E. McKenney
2014-02-06 23:45 ` Torvald Riegel
2014-02-07 4:21 ` Paul E. McKenney
2014-02-07 7:44 ` Peter Zijlstra
2014-02-07 16:50 ` Paul E. McKenney
2014-02-07 16:55 ` Will Deacon
2014-02-07 17:07 ` Peter Zijlstra
2014-02-07 17:13 ` Will Deacon
2014-02-07 17:20 ` Peter Zijlstra
2014-02-07 18:03 ` Paul E. McKenney
2014-02-07 17:46 ` Joseph S. Myers
2014-02-07 18:43 ` Torvald Riegel
2014-02-07 18:02 ` Paul E. McKenney
2014-02-10 0:28 ` Torvald Riegel
2014-02-10 0:56 ` Linus Torvalds
2014-02-10 1:16 ` Torvald Riegel
2014-02-10 1:24 ` Linus Torvalds
2014-02-10 1:46 ` Torvald Riegel
2014-02-10 2:04 ` Linus Torvalds
2014-02-10 3:21 ` Paul E. McKenney
2014-02-10 3:45 ` Paul E. McKenney
2014-02-10 11:46 ` Peter Zijlstra
2014-02-10 19:09 ` Linus Torvalds
2014-02-11 15:59 ` Paul E. McKenney
2014-02-12 6:06 ` Torvald Riegel
2014-02-12 9:19 ` Peter Zijlstra
2014-02-12 17:52 ` Paul E. McKenney
2014-02-12 18:12 ` Peter Zijlstra
2014-02-17 18:18 ` Paul E. McKenney
2014-02-17 20:38 ` Richard Biener
2014-02-17 22:14 ` Paul E. McKenney
2014-02-17 22:27 ` Torvald Riegel
2014-02-14 5:08 ` Torvald Riegel
2014-02-14 9:50 ` Peter Zijlstra
2014-02-14 19:19 ` Torvald Riegel
2014-02-12 17:50 ` Paul E. McKenney
2014-02-12 5:39 ` Torvald Riegel
2014-02-12 18:19 ` Paul E. McKenney
2014-02-12 20:22 ` Linus Torvalds
2014-02-13 0:24 ` Paul E. McKenney
2014-02-13 20:04 ` Torvald Riegel
2014-02-14 2:01 ` Paul E. McKenney
2014-02-14 4:43 ` Torvald Riegel
2014-02-14 17:29 ` Paul E. McKenney
2014-02-14 19:22 ` Torvald Riegel
2014-02-14 19:50 ` Linus Torvalds
2014-02-14 20:02 ` Linus Torvalds
2014-02-15 2:08 ` Paul E. McKenney
2014-02-15 2:44 ` Linus Torvalds
2014-02-15 2:48 ` Linus Torvalds
2014-02-15 6:35 ` Paul E. McKenney
2014-02-15 6:58 ` Paul E. McKenney
2014-02-15 18:07 ` Torvald Riegel
2014-02-17 18:59 ` Joseph S. Myers
2014-02-17 19:19 ` Will Deacon
2014-02-17 19:41 ` Torvald Riegel
2014-02-17 23:13 ` Joseph S. Myers
2014-02-15 17:45 ` Torvald Riegel
2014-02-15 18:49 ` Linus Torvalds
2014-02-17 19:55 ` Torvald Riegel
2014-02-17 20:18 ` Linus Torvalds
2014-02-17 21:21 ` Torvald Riegel
2014-02-17 22:02 ` Linus Torvalds
2014-02-17 22:25 ` Torvald Riegel
2014-02-17 22:48 ` Linus Torvalds
2014-02-17 23:42 ` Torvald Riegel
2014-02-18 0:18 ` Linus Torvalds
2014-02-18 1:26 ` Paul E. McKenney
2014-02-18 15:39 ` Torvald Riegel
2014-02-18 16:55 ` Paul E. McKenney
2014-02-18 19:57 ` Torvald Riegel
2014-02-17 23:10 ` Alec Teal
2014-02-18 0:05 ` Linus Torvalds
2014-02-18 15:31 ` Torvald Riegel
2014-02-18 16:49 ` Linus Torvalds
2014-02-18 17:16 ` Paul E. McKenney
2014-02-18 18:23 ` Peter Sewell
2014-02-18 19:00 ` Linus Torvalds
2014-02-18 19:42 ` Paul E. McKenney
2014-02-18 21:40 ` Torvald Riegel
2014-02-18 21:53 ` Peter Zijlstra
2014-02-19 9:52 ` Torvald Riegel
2014-02-18 22:58 ` Paul E. McKenney
2014-02-19 10:59 ` Torvald Riegel
2014-02-19 15:32 ` Paul E. McKenney
2014-02-19 17:56 ` Torvald Riegel
2014-02-19 22:12 ` Paul E. McKenney
2014-02-18 21:27 ` Torvald Riegel
2014-02-18 21:40 ` Peter Zijlstra
2014-02-18 21:47 ` Torvald Riegel
2014-02-19 15:23 ` David Lang
2014-02-19 18:11 ` Torvald Riegel
2014-02-18 21:47 ` Peter Zijlstra
2014-02-19 11:07 ` Torvald Riegel
2014-02-19 11:42 ` Peter Zijlstra
2014-02-18 22:14 ` Linus Torvalds
2014-02-19 14:41 ` Torvald Riegel
2014-02-19 19:49 ` Linus Torvalds
2014-02-18 3:00 ` Paul E. McKenney
2014-02-18 3:25 ` Linus Torvalds
2014-02-18 3:42 ` Linus Torvalds
2014-02-18 5:22 ` Paul E. McKenney
2014-02-18 16:17 ` Torvald Riegel
2014-02-18 17:44 ` Linus Torvalds
2014-02-18 19:40 ` Paul E. McKenney
2014-02-18 19:48 ` Torvald Riegel
2014-02-20 0:53 ` Linus Torvalds
2014-02-20 4:01 ` Paul E. McKenney
2014-02-20 4:43 ` Linus Torvalds
2014-02-20 8:30 ` Paul E. McKenney
2014-02-20 9:20 ` Paul E. McKenney
2014-02-20 17:01 ` Linus Torvalds
2014-02-20 18:12 ` Paul E. McKenney
2014-02-20 18:32 ` Linus Torvalds
2014-02-20 18:53 ` Torvald Riegel
2014-02-20 19:09 ` Linus Torvalds
2014-02-22 18:53 ` Torvald Riegel
2014-02-22 21:53 ` Linus Torvalds
2014-02-23 0:39 ` Paul E. McKenney
2014-02-23 3:50 ` Linus Torvalds
2014-02-23 9:22 ` Paul E. McKenney
2014-02-23 19:31 ` Linus Torvalds
2014-02-24 1:17 ` Paul E. McKenney
2014-02-24 1:35 ` Linus Torvalds
2014-02-24 5:00 ` Paul E. McKenney
2014-02-24 5:26 ` Linus Torvalds
2014-02-24 15:57 ` Linus Torvalds
2014-02-24 16:27 ` Richard Biener
2014-02-24 16:37 ` Linus Torvalds
2014-02-24 16:40 ` Linus Torvalds
2014-02-24 16:55 ` Michael Matz
2014-02-24 17:29 ` Paul E. McKenney
2014-02-24 17:57 ` Paul E. McKenney
2014-02-26 17:40 ` Torvald Riegel
2014-02-24 17:38 ` Linus Torvalds
2014-02-24 18:12 ` Paul E. McKenney
2014-02-26 17:34 ` Torvald Riegel
2014-02-24 17:21 ` Paul E. McKenney
2014-02-24 18:14 ` Linus Torvalds
2014-02-24 18:53 ` Paul E. McKenney
2014-02-24 19:54 ` Linus Torvalds
2014-02-24 22:37 ` Paul E. McKenney
2014-02-24 23:35 ` Linus Torvalds
2014-02-25 6:00 ` Paul E. McKenney
2014-02-26 1:47 ` Linus Torvalds
2014-02-26 5:12 ` Paul E. McKenney
2014-02-25 6:05 ` Linus Torvalds
2014-02-26 0:16 ` Paul E. McKenney
2014-02-26 3:32 ` Jeff Law
2014-02-26 5:23 ` Paul E. McKenney
2014-02-27 15:37 ` Torvald Riegel
2014-02-27 17:01 ` Linus Torvalds
2014-02-27 19:06 ` Paul E. McKenney
2014-02-27 19:47 ` Linus Torvalds
2014-02-27 20:53 ` Paul E. McKenney
2014-03-01 0:50 ` Paul E. McKenney
2014-03-01 10:06 ` Peter Sewell
2014-03-01 14:04 ` Paul E. McKenney
2014-03-02 10:05 ` Peter Sewell
2014-03-02 23:21 ` Paul E. McKenney
2014-03-02 23:44 ` Peter Sewell
2014-03-03 4:25 ` Paul E. McKenney
2014-03-03 20:44 ` Torvald Riegel
2014-03-04 22:11 ` Peter Sewell
2014-03-05 17:15 ` Torvald Riegel
2014-03-05 18:37 ` Peter Sewell
2014-03-03 19:08 ` Torvald Riegel
2014-03-03 19:20 ` Paul E. McKenney
2014-03-03 20:46 ` Torvald Riegel
2014-03-04 19:00 ` Paul E. McKenney
2014-03-04 21:35 ` Paul E. McKenney
2014-03-05 16:55 ` Torvald Riegel
2014-03-05 18:15 ` Paul E. McKenney
2014-03-07 18:33 ` Torvald Riegel
2014-03-07 19:11 ` Paul E. McKenney
2014-03-05 16:26 ` Torvald Riegel
2014-03-05 18:01 ` Paul E. McKenney
2014-03-07 17:46 ` Torvald Riegel
2014-03-07 19:02 ` Paul E. McKenney
2014-03-03 18:59 ` Torvald Riegel
2014-03-03 15:36 ` Torvald Riegel
2014-02-27 17:50 ` Paul E. McKenney
2014-02-27 19:22 ` Paul E. McKenney
2014-02-28 1:02 ` Paul E. McKenney
2014-03-03 19:29 ` Torvald Riegel
2014-03-03 19:01 ` Torvald Riegel
2014-02-20 18:56 ` Paul E. McKenney
2014-02-20 19:45 ` Linus Torvalds
2014-02-20 22:10 ` Paul E. McKenney
2014-02-20 22:52 ` Linus Torvalds
2014-02-21 18:35 ` Michael Matz
2014-02-21 19:13 ` Paul E. McKenney
2014-02-21 22:11 ` Joseph S. Myers
2014-02-21 22:37 ` Paul E. McKenney
2014-02-26 13:09 ` Torvald Riegel
2014-02-26 18:43 ` Joseph S. Myers
2014-02-27 0:53 ` Torvald Riegel
2014-02-24 13:55 ` Michael Matz
2014-02-24 17:40 ` Paul E. McKenney
2014-02-26 13:04 ` Torvald Riegel
2014-02-26 18:27 ` Paul E. McKenney
2014-02-20 18:44 ` Torvald Riegel
2014-02-20 18:56 ` Paul E. McKenney
2014-02-20 18:23 ` Torvald Riegel
[not found] ` <CAHWkzRQZ8+gOGMFNyTKjFNzpUv6d_J1G9KL0x_iCa=YCgvEojQ@mail.gmail.com>
2014-02-21 19:16 ` Linus Torvalds
2014-02-21 19:41 ` Linus Torvalds
2014-02-21 19:48 ` Peter Sewell
[not found] ` <CAHWkzRSO82jU-9dtTEjHaW2FeLcEqdZXxp5Q8cmVTTT9uhZQYw@mail.gmail.com>
2014-02-21 20:22 ` Linus Torvalds
[not found] ` <CAHWkzRRxqhH+DnuQHu9bM4ywGBen3oqtT8W4Xqt1CFAHy2WQRg@mail.gmail.com>
2014-02-21 19:24 ` Paul E. McKenney
2014-02-20 17:54 ` Torvald Riegel
2014-02-20 18:12 ` Paul E. McKenney
2014-02-20 17:49 ` Torvald Riegel
2014-02-20 18:25 ` Linus Torvalds
2014-02-20 19:02 ` Linus Torvalds
2014-02-20 19:06 ` Linus Torvalds
2014-02-20 17:26 ` Torvald Riegel
2014-02-20 18:18 ` Paul E. McKenney
2014-02-22 18:31 ` Torvald Riegel
2014-02-22 20:18 ` Paul E. McKenney
2014-02-20 17:16 ` Torvald Riegel
2014-02-20 17:35 ` Linus Torvalds
2014-02-20 18:12 ` Torvald Riegel
2014-02-20 18:26 ` Paul E. McKenney
2014-02-18 5:02 ` Paul E. McKenney
2014-02-18 15:56 ` Torvald Riegel
2014-02-18 16:51 ` Paul E. McKenney
2014-02-17 20:23 ` Paul E. McKenney
2014-02-17 21:06 ` Torvald Riegel
2014-02-15 17:30 ` Torvald Riegel
2014-02-15 19:16 ` Linus Torvalds
2014-02-17 22:10 ` Torvald Riegel
2014-02-17 22:32 ` Linus Torvalds
2014-02-17 23:17 ` Torvald Riegel
2014-02-18 0:09 ` Linus Torvalds
2014-02-18 16:39 ` Torvald Riegel
2014-02-10 11:48 ` Peter Zijlstra
2014-02-10 11:49 ` Will Deacon
2014-02-10 12:05 ` Peter Zijlstra
2014-02-10 15:06 ` Paul E. McKenney
2014-02-10 16:23 ` Will Deacon
2014-02-07 18:45 ` Torvald Riegel
2014-02-10 0:07 ` Torvald Riegel
2014-02-10 3:52 ` Paul E. McKenney
2014-02-12 5:13 ` Torvald Riegel
2014-02-12 18:26 ` Paul E. McKenney
2014-02-06 21:09 ` Torvald Riegel
2014-02-06 21:55 ` Paul E. McKenney [this message]
2014-02-06 22:58 ` Torvald Riegel
2014-02-07 4:06 ` Paul E. McKenney
2014-02-07 9:13 ` Torvald Riegel
2014-02-07 16:44 ` Paul E. McKenney
2014-02-06 22:13 ` Joseph S. Myers
2014-02-06 23:25 ` Torvald Riegel
2014-02-06 23:33 ` Joseph S. Myers
2014-02-07 12:01 ` Will Deacon
2014-02-07 16:48 ` Paul E. McKenney
2014-02-18 12:12 Peter Sewell
2014-02-18 12:54 ` Peter Zijlstra
2014-02-18 16:09 ` Peter Sewell
2014-02-18 14:57 ` Paul E. McKenney
2014-02-18 15:17 ` Mark Batty
2014-02-18 17:17 ` Paul E. McKenney
2014-02-18 15:33 ` Peter Sewell
2014-02-18 16:47 ` Paul E. McKenney
2014-02-18 17:38 ` Linus Torvalds
2014-02-18 18:21 ` Peter Sewell
2014-02-18 18:49 ` Linus Torvalds
2014-02-18 19:47 ` Paul E. McKenney
2014-02-18 20:46 ` Torvald Riegel
2014-02-18 20:43 ` Torvald Riegel
2014-02-18 21:30 ` Paul E. McKenney
2014-02-18 23:48 ` Peter Sewell
2014-02-19 9:46 ` Torvald Riegel
2014-02-26 3:06 George Spelvin
2014-02-26 5:22 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140206215521.GI4250@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=triegel@redhat.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).