x86, paravirt: Add a global synchronization point for pvclock
in [Kernel]
|
From: Jeremy Fitzhardinge on 14 Jul 2010 14:20 On 07/14/2010 11:08 AM, H. Peter Anvin wrote: > Noone has talked about strict ordering between volatiles and > (non-volatile) memory ops in general. I have been talking about > volatile to volatile ordering, and I thought I'd been very clear about that. > OK. > H.J., we're having a debate about the actual semantics of "volatile", > especially "asm volatile" in gcc. In particular, I believe that > volatile operations should not be possible to reorder with regards to > each other, and the kernel depends on that fact. > I think we should consider that deprecated and rely on dependencies and clobbers. J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H.J. Lu on 14 Jul 2010 14:30 On Wed, Jul 14, 2010 at 11:08 AM, H. Peter Anvin <hpa(a)zytor.com> wrote: > [Adding H.J. to the Cc: list] > > On 07/14/2010 10:57 AM, Jeremy Fitzhardinge wrote: >>>> >>> I/O ports, for example. >>> >> >> Yes, it looks like they should have memory barriers if we want them to >> be ordered with respect to normal writes; afaict "asm volatile" has >> never had strict ordering wrt memory ops. >> > > Noone has talked about strict ordering between volatiles and > (non-volatile) memory ops in general. �I have been talking about > volatile to volatile ordering, and I thought I'd been very clear about that. > > H.J., we're having a debate about the actual semantics of "volatile", > especially "asm volatile" in gcc. �In particular, I believe that > volatile operations should not be possible to reorder with regards to > each other, and the kernel depends on that fact. > > � � � �-hpa > > P.S: gcc 4.4 seems to handle "const volatile" incorrectly, probably by > applying CSE to those values. > > There are some discussions on: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html Are they related? -- H.J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jul 2010 14:30 On 07/14/2010 11:15 AM, Jeremy Fitzhardinge wrote: > > I think we should consider that deprecated and rely on dependencies and > clobbers. > I don't think that's practical in general. If the compiler is *that broken*, I don't see how it is usable at all. As Linus indicated, I don't think we can assume the gcc documentation to accurately reflect the intent of the gcc team, mostly because I think it often lags way behind what they're thinking. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 14 Jul 2010 14:40 On Wed, Jul 14, 2010 at 11:15 AM, Jeremy Fitzhardinge <jeremy(a)goop.org> wrote: > > I think we should consider that deprecated and rely on dependencies and > clobbers. That makes no sense. According to that logic, "asm volatile" has no semantic meaning at ALL. That's just crazy talk. The sane compiler semantics for "asm volatile" is that it acts as a volatile memory access. That's what the naming implies, and it has valid semantics that also happen to match the historical semantics. It means that it cannot be removed or duplicated, and it cannot be re-ordered wrt other volatile accesses (whether "asm volatile" or a traditional C volatile memory access). I agree that we could just add memory clobbers to them all, but my objection to that is that it just makes the whole keyword totally pointless. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jul 2010 15:10
On 07/14/2010 11:18 AM, H.J. Lu wrote: > > There are some discussions on: > > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html > > Are they related? > Not directly as far as I can tell. The issue is if gcc can ever reorder, duplicate or elide a volatile operation (either asm volatile or a volatile-annotated memory reference.) In my (and Linus') opinion, this would be an incredibly serious bug. The gcc 4.4 issue, which is separate from the definition issue, is that it seems to assume that it can elide references to "const volatile" objects. "const volatile" should mean a value that could change at any time but which is a bug to write to -- for example a readonly hardware register. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |