From: Nick Piggin <piggin@cyberone.com.au> To: Satyam Sharma <satyam@infradead.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>, paulmck@linux.vnet.ibm.com, Herbert Xu <herbert@gondor.apana.org.au>, Paul Mackerras <paulus@samba.org>, Christoph Lameter <clameter@sgi.com>, Chris Snook <csnook@redhat.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arch@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, ak@suse.de, heiko.carstens@de.ibm.com, davem@davemloft.net, schwidefsky@de.ibm.com, wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com, cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com, jesper.juhl@gmail.com, segher@kernel.crashing.org Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures Date: Fri, 17 Aug 2007 22:56:41 +1000 [thread overview] Message-ID: <46C59B09.8040004@cyberone.com.au> (raw) In-Reply-To: <alpine.LFD.0.999.0708171737060.3666@enigma.security.iitk.ac.in> Satyam Sharma wrote: > >On Fri, 17 Aug 2007, Nick Piggin wrote: > > >>Satyam Sharma wrote: >> >>>On Fri, 17 Aug 2007, Nick Piggin wrote: >>> >>>>Satyam Sharma wrote: >>>> >>>>It is very obvious. msleep calls schedule() (ie. sleeps), which is >>>>always a barrier. >>>> >>>Probably you didn't mean that, but no, schedule() is not barrier because >>>it sleeps. It's a barrier because it's invisible. >>> >>Where did I say it is a barrier because it sleeps? >> > >Just below. What you wrote: > > >>It is always a barrier because, at the lowest level, schedule() (and thus >>anything that sleeps) is defined to always be a barrier. >> > >"It is always a barrier because, at the lowest level, anything that sleeps >is defined to always be a barrier". > ... because it must call schedule and schedule is a barrier. >>Regardless of >>whatever obscure means the compiler might need to infer the barrier. >> >>In other words, you can ignore those obscure details because schedule() is >>always going to have an explicit barrier in it. >> > >I didn't quite understand what you said here, so I'll tell what I think: > >* foo() is a compiler barrier if the definition of foo() is invisible to > the compiler at a callsite. > >* foo() is also a compiler barrier if the definition of foo() includes > a barrier, and it is inlined at the callsite. > >If the above is wrong, or if there's something else at play as well, >do let me know. > Right. >>>>The "unobvious" thing is that you wanted to know how the compiler knows >>>>a function is a barrier -- answer is that if it does not *know* it is not >>>>a barrier, it must assume it is a barrier. >>>> >>>True, that's clearly what happens here. But are you're definitely joking >>>that this is "obvious" in terms of code-clarity, right? >>> >>No. If you accept that barrier() is implemented correctly, and you know >>that sleeping is defined to be a barrier, >> > >Curiously, that's the second time you've said "sleeping is defined to >be a (compiler) barrier". > _In Linux,_ sleeping is defined to be a compiler barrier. >How does the compiler even know if foo() is >a function that "sleeps"? Do compilers have some notion of "sleeping" >to ensure they automatically assume a compiler barrier whenever such >a function is called? Or are you saying that the compiler can see the >barrier() inside said function ... nopes, you're saying quite the >opposite below. > You're getting too worried about the compiler implementation. Start by assuming that it does work ;) >>then its perfectly clear. You >>don't have to know how the compiler "knows" that some function contains >>a barrier. >> > >I think I do, why not? Would appreciate if you could elaborate on this. > If a function is not completely visible to the compiler (so it can't determine whether a barrier could be in it or not), then it must always assume it will contain a barrier so it always does the right thing.
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <piggin@cyberone.com.au> To: Satyam Sharma <satyam@infradead.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>, paulmck@linux.vnet.ibm.com, Herbert Xu <herbert@gondor.apana.org.au>, Paul Mackerras <paulus@samba.org>, Christoph Lameter <clameter@sgi.com>, Chris Snook <csnook@redhat.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arch@vger.kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, ak@suse.de, heiko.carstens@de.ibm.com, davem@davemloft.net, schwidefsky@de.ibm.com, wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com, cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com, jesper.juhl@gmail.com, segher@kernel.crashing.org Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures Date: Fri, 17 Aug 2007 22:56:41 +1000 [thread overview] Message-ID: <46C59B09.8040004@cyberone.com.au> (raw) In-Reply-To: <alpine.LFD.0.999.0708171737060.3666@enigma.security.iitk.ac.in> Satyam Sharma wrote: > >On Fri, 17 Aug 2007, Nick Piggin wrote: > > >>Satyam Sharma wrote: >> >>>On Fri, 17 Aug 2007, Nick Piggin wrote: >>> >>>>Satyam Sharma wrote: >>>> >>>>It is very obvious. msleep calls schedule() (ie. sleeps), which is >>>>always a barrier. >>>> >>>Probably you didn't mean that, but no, schedule() is not barrier because >>>it sleeps. It's a barrier because it's invisible. >>> >>Where did I say it is a barrier because it sleeps? >> > >Just below. What you wrote: > > >>It is always a barrier because, at the lowest level, schedule() (and thus >>anything that sleeps) is defined to always be a barrier. >> > >"It is always a barrier because, at the lowest level, anything that sleeps >is defined to always be a barrier". > ... because it must call schedule and schedule is a barrier. >>Regardless of >>whatever obscure means the compiler might need to infer the barrier. >> >>In other words, you can ignore those obscure details because schedule() is >>always going to have an explicit barrier in it. >> > >I didn't quite understand what you said here, so I'll tell what I think: > >* foo() is a compiler barrier if the definition of foo() is invisible to > the compiler at a callsite. > >* foo() is also a compiler barrier if the definition of foo() includes > a barrier, and it is inlined at the callsite. > >If the above is wrong, or if there's something else at play as well, >do let me know. > Right. >>>>The "unobvious" thing is that you wanted to know how the compiler knows >>>>a function is a barrier -- answer is that if it does not *know* it is not >>>>a barrier, it must assume it is a barrier. >>>> >>>True, that's clearly what happens here. But are you're definitely joking >>>that this is "obvious" in terms of code-clarity, right? >>> >>No. If you accept that barrier() is implemented correctly, and you know >>that sleeping is defined to be a barrier, >> > >Curiously, that's the second time you've said "sleeping is defined to >be a (compiler) barrier". > _In Linux,_ sleeping is defined to be a compiler barrier. >How does the compiler even know if foo() is >a function that "sleeps"? Do compilers have some notion of "sleeping" >to ensure they automatically assume a compiler barrier whenever such >a function is called? Or are you saying that the compiler can see the >barrier() inside said function ... nopes, you're saying quite the >opposite below. > You're getting too worried about the compiler implementation. Start by assuming that it does work ;) >>then its perfectly clear. You >>don't have to know how the compiler "knows" that some function contains >>a barrier. >> > >I think I do, why not? Would appreciate if you could elaborate on this. > If a function is not completely visible to the compiler (so it can't determine whether a barrier could be in it or not), then it must always assume it will contain a barrier so it always does the right thing.
next prev parent reply other threads:[~2007-08-17 12:57 UTC|newest] Thread overview: 333+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-08-09 13:14 [PATCH 0/24] make atomic_read() behave consistently across all architectures Chris Snook 2007-08-09 12:41 ` Arnd Bergmann 2007-08-09 14:29 ` Chris Snook 2007-08-09 15:30 ` Arnd Bergmann 2007-08-14 22:31 ` Christoph Lameter 2007-08-14 22:45 ` Chris Snook 2007-08-14 22:51 ` Christoph Lameter 2007-08-14 23:08 ` Satyam Sharma 2007-08-14 23:04 ` Chris Snook 2007-08-14 23:14 ` Christoph Lameter 2007-08-15 6:49 ` Herbert Xu 2007-08-15 6:49 ` Herbert Xu 2007-08-15 8:18 ` Heiko Carstens 2007-08-15 13:53 ` Stefan Richter 2007-08-15 14:35 ` Satyam Sharma 2007-08-15 14:52 ` Herbert Xu 2007-08-15 16:09 ` Stefan Richter 2007-08-15 16:27 ` Paul E. McKenney 2007-08-15 17:13 ` Satyam Sharma 2007-08-15 18:31 ` Segher Boessenkool 2007-08-15 18:57 ` Paul E. McKenney 2007-08-15 19:54 ` Satyam Sharma 2007-08-15 20:17 ` Paul E. McKenney 2007-08-15 20:52 ` Segher Boessenkool 2007-08-15 22:42 ` Paul E. McKenney 2007-08-15 20:47 ` Segher Boessenkool 2007-08-16 0:36 ` Satyam Sharma 2007-08-16 0:36 ` (unknown) Satyam Sharma 2007-08-16 0:32 ` your mail Herbert Xu 2007-08-16 0:58 ` [PATCH 0/24] make atomic_read() behave consistently across all architectures Satyam Sharma 2007-08-16 0:51 ` Herbert Xu 2007-08-16 1:18 ` Satyam Sharma 2007-08-16 1:38 ` Segher Boessenkool 2007-08-15 21:05 ` [PATCH 0/24] make atomic_read() behave consistently across all architectures Segher Boessenkool 2007-08-15 22:44 ` Paul E. McKenney 2007-08-16 1:23 ` Segher Boessenkool 2007-08-16 2:22 ` Paul E. McKenney 2007-08-15 19:58 ` Stefan Richter 2007-08-16 0:39 ` [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert() Satyam Sharma 2007-08-24 11:59 ` Denys Vlasenko 2007-08-24 12:07 ` Andi Kleen 2007-08-24 12:12 ` Kenn Humborg 2007-08-24 12:12 ` Kenn Humborg 2007-08-24 14:25 ` Denys Vlasenko 2007-08-24 17:34 ` Linus Torvalds 2007-08-24 13:30 ` Satyam Sharma 2007-08-24 17:06 ` Christoph Lameter 2007-08-24 20:26 ` Denys Vlasenko 2007-08-24 20:34 ` Chris Snook 2007-08-24 16:19 ` Luck, Tony 2007-08-24 16:19 ` Luck, Tony 2007-08-15 16:13 ` [PATCH 0/24] make atomic_read() behave consistently across all architectures Chris Snook 2007-08-15 23:40 ` Herbert Xu 2007-08-15 23:51 ` Paul E. McKenney 2007-08-16 1:30 ` Segher Boessenkool 2007-08-16 2:30 ` Paul E. McKenney 2007-08-16 19:33 ` Segher Boessenkool 2007-08-16 1:26 ` Segher Boessenkool 2007-08-16 2:23 ` Nick Piggin 2007-08-16 19:32 ` Segher Boessenkool 2007-08-17 2:19 ` Nick Piggin 2007-08-17 3:16 ` Paul Mackerras 2007-08-17 3:32 ` Nick Piggin 2007-08-17 3:50 ` Linus Torvalds 2007-08-17 23:59 ` Paul E. McKenney 2007-08-18 0:09 ` Herbert Xu 2007-08-18 1:08 ` Paul E. McKenney 2007-08-18 1:24 ` Christoph Lameter 2007-08-18 1:41 ` Satyam Sharma 2007-08-18 4:13 ` Linus Torvalds 2007-08-18 13:36 ` Satyam Sharma 2007-08-18 21:54 ` Paul E. McKenney 2007-08-18 22:41 ` Linus Torvalds 2007-08-18 23:19 ` Paul E. McKenney 2007-08-24 12:19 ` Denys Vlasenko 2007-08-24 17:19 ` Linus Torvalds 2007-08-18 21:56 ` Paul E. McKenney 2007-08-20 13:31 ` Chris Snook 2007-08-20 22:04 ` Segher Boessenkool 2007-08-20 22:48 ` Russell King 2007-08-20 23:02 ` Segher Boessenkool 2007-08-21 0:05 ` Paul E. McKenney 2007-08-21 7:08 ` Russell King 2007-08-21 7:05 ` Russell King 2007-08-21 9:33 ` Paul Mackerras 2007-08-21 11:37 ` Andi Kleen 2007-08-21 14:48 ` Segher Boessenkool 2007-08-21 16:16 ` Paul E. McKenney 2007-08-21 22:51 ` Valdis.Kletnieks 2007-08-22 0:50 ` Paul E. McKenney 2007-08-22 21:38 ` Adrian Bunk 2007-08-21 14:39 ` Segher Boessenkool 2007-08-17 3:42 ` Linus Torvalds 2007-08-17 5:18 ` Paul E. McKenney 2007-08-17 5:56 ` Satyam Sharma 2007-08-17 7:26 ` Nick Piggin 2007-08-17 8:47 ` Satyam Sharma 2007-08-17 9:15 ` Nick Piggin 2007-08-17 10:12 ` Satyam Sharma 2007-08-17 12:14 ` Nick Piggin 2007-08-17 13:05 ` Satyam Sharma 2007-08-17 9:48 ` Paul Mackerras 2007-08-17 10:23 ` Satyam Sharma 2007-08-17 22:49 ` Segher Boessenkool 2007-08-17 23:51 ` Satyam Sharma 2007-08-17 23:55 ` Segher Boessenkool 2007-08-17 6:42 ` Geert Uytterhoeven 2007-08-17 8:52 ` Andi Kleen 2007-08-17 10:08 ` Satyam Sharma 2007-08-17 22:29 ` Segher Boessenkool 2007-08-17 17:37 ` Segher Boessenkool 2007-08-14 23:26 ` Paul E. McKenney 2007-08-15 10:35 ` Stefan Richter 2007-08-15 12:04 ` Herbert Xu 2007-08-15 12:31 ` Satyam Sharma 2007-08-15 13:08 ` Stefan Richter 2007-08-15 13:11 ` Stefan Richter 2007-08-15 13:47 ` Satyam Sharma 2007-08-15 14:25 ` Paul E. McKenney 2007-08-15 15:33 ` Herbert Xu 2007-08-15 16:08 ` Paul E. McKenney 2007-08-15 17:18 ` Satyam Sharma 2007-08-15 17:33 ` Paul E. McKenney 2007-08-15 18:05 ` Satyam Sharma 2007-08-15 17:55 ` Satyam Sharma 2007-08-15 19:07 ` Paul E. McKenney 2007-08-15 21:07 ` Segher Boessenkool 2007-08-15 20:58 ` Segher Boessenkool 2007-08-15 18:19 ` David Howells 2007-08-15 18:45 ` Paul E. McKenney 2007-08-15 23:41 ` Herbert Xu 2007-08-15 23:53 ` Paul E. McKenney 2007-08-16 0:12 ` Herbert Xu 2007-08-16 0:23 ` Paul E. McKenney 2007-08-16 0:30 ` Herbert Xu 2007-08-16 0:49 ` Paul E. McKenney 2007-08-16 0:53 ` Herbert Xu 2007-08-16 1:14 ` Paul E. McKenney 2007-08-15 18:31 ` Segher Boessenkool 2007-08-15 19:40 ` Satyam Sharma 2007-08-15 20:42 ` Segher Boessenkool 2007-08-16 1:23 ` Satyam Sharma 2007-08-15 23:22 ` Paul Mackerras 2007-08-16 0:26 ` Christoph Lameter 2007-08-16 0:34 ` Paul Mackerras 2007-08-16 0:40 ` Christoph Lameter 2007-08-16 0:39 ` Paul E. McKenney 2007-08-16 0:42 ` Christoph Lameter 2007-08-16 0:53 ` Paul E. McKenney 2007-08-16 0:59 ` Christoph Lameter 2007-08-16 1:14 ` Paul E. McKenney 2007-08-16 1:41 ` Christoph Lameter 2007-08-16 2:15 ` Satyam Sharma 2007-08-16 2:08 ` Herbert Xu 2007-08-16 2:18 ` Christoph Lameter 2007-08-16 3:23 ` Paul Mackerras 2007-08-16 3:33 ` Herbert Xu 2007-08-16 3:48 ` Paul Mackerras 2007-08-16 4:03 ` Herbert Xu 2007-08-16 4:34 ` Paul Mackerras 2007-08-16 5:37 ` Herbert Xu 2007-08-16 6:00 ` Paul Mackerras 2007-08-16 18:50 ` Christoph Lameter 2007-08-16 18:48 ` Christoph Lameter 2007-08-16 19:44 ` Segher Boessenkool 2007-08-16 2:18 ` Chris Friesen 2007-08-16 2:32 ` Paul E. McKenney 2007-08-16 1:51 ` Paul Mackerras 2007-08-16 2:00 ` Herbert Xu 2007-08-16 2:05 ` Paul Mackerras 2007-08-16 2:11 ` Herbert Xu 2007-08-16 2:35 ` Paul E. McKenney 2007-08-16 3:15 ` Paul Mackerras 2007-08-16 3:43 ` Herbert Xu 2007-08-16 2:15 ` Christoph Lameter 2007-08-16 2:17 ` Christoph Lameter 2007-08-16 2:33 ` Satyam Sharma 2007-08-16 3:01 ` Satyam Sharma 2007-08-16 4:11 ` Paul Mackerras 2007-08-16 5:39 ` Herbert Xu 2007-08-16 6:56 ` Paul Mackerras 2007-08-16 7:09 ` Herbert Xu 2007-08-16 8:06 ` Stefan Richter 2007-08-16 8:10 ` Herbert Xu 2007-08-16 9:54 ` Stefan Richter 2007-08-16 10:31 ` Stefan Richter 2007-08-16 10:42 ` Herbert Xu 2007-08-16 16:34 ` Paul E. McKenney 2007-08-16 23:59 ` Herbert Xu 2007-08-17 1:01 ` Paul E. McKenney 2007-08-17 7:39 ` Satyam Sharma 2007-08-17 14:31 ` Paul E. McKenney 2007-08-17 18:31 ` Satyam Sharma 2007-08-17 18:56 ` Paul E. McKenney 2007-08-17 3:15 ` Nick Piggin 2007-08-17 4:02 ` Paul Mackerras 2007-08-17 4:39 ` Nick Piggin 2007-08-17 7:25 ` Stefan Richter 2007-08-17 8:06 ` Nick Piggin 2007-08-17 8:58 ` Satyam Sharma 2007-08-17 9:15 ` Nick Piggin 2007-08-17 10:03 ` Satyam Sharma 2007-08-17 11:50 ` Nick Piggin 2007-08-17 12:50 ` Satyam Sharma 2007-08-17 12:56 ` Nick Piggin [this message] 2007-08-17 12:56 ` Nick Piggin 2007-08-18 2:15 ` Satyam Sharma 2007-08-17 10:48 ` Stefan Richter 2007-08-17 10:58 ` Stefan Richter 2007-08-18 14:35 ` LDD3 pitfalls (was Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures) Stefan Richter 2007-08-20 13:28 ` Chris Snook 2007-08-17 22:14 ` [PATCH 0/24] make atomic_read() behave consistently across all architectures Segher Boessenkool 2007-08-17 5:04 ` Paul Mackerras 2007-08-16 10:35 ` Herbert Xu 2007-08-16 19:48 ` Chris Snook 2007-08-17 0:02 ` Herbert Xu 2007-08-17 2:04 ` Chris Snook 2007-08-17 2:13 ` Herbert Xu 2007-08-17 2:31 ` Nick Piggin 2007-08-17 5:09 ` Paul Mackerras 2007-08-17 5:32 ` Herbert Xu 2007-08-17 5:41 ` Paul Mackerras 2007-08-17 8:28 ` Satyam Sharma 2007-08-16 14:48 ` Ilpo Järvinen 2007-08-16 16:19 ` Stefan Richter 2007-08-16 19:55 ` Chris Snook 2007-08-16 20:20 ` Christoph Lameter 2007-08-17 1:02 ` Paul E. McKenney 2007-08-17 1:28 ` Herbert Xu 2007-08-17 5:07 ` Paul E. McKenney 2007-08-17 2:16 ` Paul Mackerras 2007-08-17 3:03 ` Linus Torvalds 2007-08-17 3:43 ` Paul Mackerras 2007-08-17 3:53 ` Herbert Xu 2007-08-17 6:26 ` Satyam Sharma 2007-08-17 8:38 ` Nick Piggin 2007-08-17 9:14 ` Satyam Sharma 2007-08-17 9:31 ` Nick Piggin 2007-08-17 10:55 ` Satyam Sharma 2007-08-17 12:39 ` Nick Piggin 2007-08-17 12:39 ` Nick Piggin 2007-08-17 13:36 ` Satyam Sharma 2007-08-17 16:48 ` Linus Torvalds 2007-08-17 18:50 ` Chris Friesen 2007-08-17 18:50 ` Chris Friesen 2007-08-17 18:54 ` Arjan van de Ven 2007-08-17 19:49 ` Paul E. McKenney 2007-08-17 19:49 ` Arjan van de Ven 2007-08-17 20:12 ` Paul E. McKenney 2007-08-17 19:08 ` Linus Torvalds 2007-08-20 13:15 ` Chris Snook 2007-08-20 13:15 ` Chris Snook 2007-08-20 13:32 ` Herbert Xu 2007-08-20 13:38 ` Chris Snook 2007-08-20 22:07 ` Segher Boessenkool 2007-08-21 5:46 ` Linus Torvalds 2007-08-21 7:04 ` David Miller 2007-08-21 13:50 ` Chris Snook 2007-08-21 14:59 ` Segher Boessenkool 2007-08-21 16:31 ` Satyam Sharma 2007-08-21 16:43 ` Linus Torvalds 2007-09-09 18:02 ` Denys Vlasenko 2007-09-09 18:18 ` Arjan van de Ven 2007-09-10 10:56 ` Denys Vlasenko 2007-09-10 11:15 ` Herbert Xu 2007-09-10 12:22 ` Kyle Moffett 2007-09-10 12:22 ` Kyle Moffett 2007-09-10 13:38 ` Denys Vlasenko 2007-09-10 13:38 ` Denys Vlasenko 2007-09-10 14:16 ` Denys Vlasenko 2007-09-10 14:16 ` Denys Vlasenko 2007-09-10 15:09 ` Linus Torvalds 2007-09-10 16:46 ` Denys Vlasenko 2007-09-10 19:59 ` Kyle Moffett 2007-09-10 19:59 ` Kyle Moffett 2007-09-10 18:59 ` Christoph Lameter 2007-09-10 23:19 ` [PATCH] Document non-semantics of atomic_read() and atomic_set() Chris Snook 2007-09-10 23:19 ` Chris Snook 2007-09-10 23:44 ` Paul E. McKenney 2007-09-10 23:44 ` Paul E. McKenney 2007-09-11 19:35 ` Christoph Lameter 2007-09-11 19:35 ` Christoph Lameter 2007-09-10 14:51 ` [PATCH 0/24] make atomic_read() behave consistently across all architectures Arjan van de Ven 2007-09-10 14:38 ` Denys Vlasenko 2007-09-10 17:02 ` Arjan van de Ven 2007-08-17 11:08 ` Stefan Richter 2007-08-17 22:09 ` Segher Boessenkool 2007-08-17 22:09 ` Segher Boessenkool 2007-08-17 17:41 ` Segher Boessenkool 2007-08-17 18:38 ` Satyam Sharma 2007-08-17 23:17 ` Segher Boessenkool 2007-08-17 23:17 ` Segher Boessenkool 2007-08-17 23:55 ` Satyam Sharma 2007-08-18 0:04 ` Segher Boessenkool 2007-08-18 0:04 ` Segher Boessenkool 2007-08-18 1:56 ` Satyam Sharma 2007-08-18 2:15 ` Segher Boessenkool 2007-08-18 2:15 ` Segher Boessenkool 2007-08-18 3:33 ` Satyam Sharma 2007-08-18 5:18 ` Segher Boessenkool 2007-08-18 5:18 ` Segher Boessenkool 2007-08-18 13:20 ` Satyam Sharma 2007-09-10 18:59 ` Christoph Lameter 2007-09-10 20:54 ` Paul E. McKenney 2007-09-10 21:36 ` Christoph Lameter 2007-09-10 21:50 ` Paul E. McKenney 2007-09-11 2:27 ` Segher Boessenkool 2007-09-11 2:27 ` Segher Boessenkool 2007-08-16 21:08 ` Luck, Tony 2007-08-16 21:08 ` Luck, Tony 2007-08-16 19:55 ` Chris Snook 2007-08-16 18:54 ` Christoph Lameter 2007-08-16 20:07 ` Paul E. McKenney 2007-08-16 3:05 ` Paul Mackerras 2007-08-16 19:39 ` Segher Boessenkool 2007-08-16 2:07 ` Segher Boessenkool 2007-08-24 12:50 ` Denys Vlasenko 2007-08-24 17:15 ` Christoph Lameter 2007-08-24 20:21 ` Denys Vlasenko 2007-08-16 3:37 ` Bill Fink 2007-08-16 5:20 ` Satyam Sharma 2007-08-16 5:57 ` Satyam Sharma 2007-08-16 9:25 ` Satyam Sharma 2007-08-16 21:00 ` Segher Boessenkool 2007-08-17 4:32 ` Satyam Sharma 2007-08-17 22:38 ` Segher Boessenkool 2007-08-18 14:42 ` Satyam Sharma 2007-08-16 20:50 ` Segher Boessenkool 2007-08-16 22:40 ` David Schwartz 2007-08-17 4:36 ` Satyam Sharma 2007-08-17 4:24 ` Satyam Sharma 2007-08-17 22:34 ` Segher Boessenkool 2007-08-15 19:59 ` Christoph Lameter
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=46C59B09.8040004@cyberone.com.au \ --to=piggin@cyberone.com.au \ --cc=ak@suse.de \ --cc=akpm@linux-foundation.org \ --cc=cfriesen@nortel.com \ --cc=clameter@sgi.com \ --cc=csnook@redhat.com \ --cc=davem@davemloft.net \ --cc=heiko.carstens@de.ibm.com \ --cc=herbert@gondor.apana.org.au \ --cc=horms@verge.net.au \ --cc=jesper.juhl@gmail.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=paulmck@linux.vnet.ibm.com \ --cc=paulus@samba.org \ --cc=rpjday@mindspring.com \ --cc=satyam@infradead.org \ --cc=schwidefsky@de.ibm.com \ --cc=segher@kernel.crashing.org \ --cc=stefanr@s5r6.in-berlin.de \ --cc=torvalds@linux-foundation.org \ --cc=wensong@linux-vs.org \ --cc=wjiang@resilience.com \ --cc=zlynx@acm.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.