x86, paravirt: Add a global synchronization point for pvclock
in [Kernel]
|
From: Jeremy Fitzhardinge on 13 Jul 2010 14:30 On 07/13/2010 10:59 AM, Linus Torvalds wrote: > Btw, this second patch was a bit more aggressive than the first one, > and actually removes the "memory" clobber entirely, and the fake cast > of the target type. > > That shouldn't matter _except_ if people actually use cmpxchg to > implement their own locking, since now the compiler could potentially > move unrelated memory references around the lock. Of course, if you > use cmpxchg to implement your own locking, you're probably doing > something wrong anyway (ie you'll get the wrong memory barriers on > various architectures), so it should all be fine. > There are some places which rely on xchg/cmpxchg being a barrier in arch-specific code. For example, the Xen code uses as part of the shared memory protocol with the hypervisor. > But I thought I'd mention it. And I don't really know how much gcc > moves memory accesses around a "asm volatile" - the gcc docs are > historically very vague ("volatile asms aren't moved around > 'significantly'", whatever 'significant' means) > "asm volatile"'s only real meaning is that it will not get elided if it appears its output is unused (assuming it is reachable at all). I don't think you can consider it having any meaningful effects on ordering. 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 13 Jul 2010 18:20 On 07/13/2010 11:21 AM, Jeremy Fitzhardinge wrote: > > "asm volatile"'s only real meaning is that it will not get elided if it > appears its output is unused (assuming it is reachable at all). I don't > think you can consider it having any meaningful effects on ordering. > Actually, I believe volatile operations (including asm volatile) are strictly ordered *with respect to other volatile operations*. As such I would think we'd want to keep the "memory" clobber here, to make it strictly ordered with regards to *all* memory operations. As for the concept in this patch, it's obviously the right thing, but as Linus said elsewhere it's incomplete. Conceptually: Acked-by: H. Peter Anvin <hpa(a)zytor.com> Unfortunately I can't write the productization patch right now since I have a plane to catch in about an hour, but if noone beats me to it I'll to it Thursday. -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: Jeremy Fitzhardinge on 13 Jul 2010 19:50 On 07/13/2010 03:14 PM, H. Peter Anvin wrote: > Actually, I believe volatile operations (including asm volatile) are > strictly ordered *with respect to other volatile operations*. The documentation makes no reference to that property; in fact it suggests it is outright not true: Note that even a volatile `asm' instruction can be moved relative to other code, including across jump instructions. For example, on many targets there is a system register which can be set to control the rounding mode of floating point operations. You might try setting it with a volatile `asm', like this PowerPC example: asm volatile("mtfsf 255,%0" : : "f" (fpenv)); sum = x + y; This will not work reliably, as the compiler may move the addition back before the volatile `asm'. To make it work you need to add an artificial dependency to the `asm' referencing a variable in the code you don't want moved, for example: asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv)); sum = x + y; Similarly, you can't expect a sequence of volatile `asm' instructions to remain perfectly consecutive. [...] An `asm' instruction without any output operands will be treated identically to a volatile `asm' instruction. > As such I > would think we'd want to keep the "memory" clobber here, to make it > strictly ordered with regards to *all* memory operations. > That would keep its overall effect consistent. 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: Linus Torvalds on 13 Jul 2010 20:20 On Tue, Jul 13, 2010 at 4:49 PM, Jeremy Fitzhardinge <jeremy(a)goop.org> wrote: > > The documentation makes no reference to that property; in fact it > suggests it is outright not true: The gcc documentation wrt inline asm's is totally worthless. Don't even bother quoting it - because the gcc people themselves have never cared. If the docs ever end up not matching what they want to do, they will just change the documentation. In other words, at least historically the docs are not in any way meaningful. They are not a "these are the semantics we guarantee", they are just random noise. As I mentioned, the docs historically just said something like "will not be moved significantly", and apparently they've been changed to be something else. The only thing that has ever been meaningful is "this works". And, of course, that has changed over time too, including actual recommendations on how to make something work (as mentioned, iirc "+" was only valid on register constraints, and "+m" used to not be allowed _or_ recommended, these days it's the only way to do certain things). It's irritating, because in other circumstances, gcc people take the reverse approach, and consider paper documentation more important than actual implementation issues. So sometimes they say "hey, this is the spec", but when it comes to their own docs, the answer has historically been "we'll just change the spec". 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: Jeremy Fitzhardinge on 14 Jul 2010 13:30
On 07/13/2010 05:15 PM, Linus Torvalds wrote: > The gcc documentation wrt inline asm's is totally worthless. Don't > even bother quoting it - because the gcc people themselves have never > cared. If the docs ever end up not matching what they want to do, they > will just change the documentation. > > In other words, at least historically the docs are not in any way > meaningful. They are not a "these are the semantics we guarantee", > they are just random noise. As I mentioned, the docs historically just > said something like "will not be moved significantly", and apparently > they've been changed to be something else. > > Sure, I completely agree. At the moment the docs say "asm volatile guarantees nothing", and we can work with that. So long as we don't expect asm volatile to mean anything more (ie, magic semantics involving reordering), everyone is happy. BTW, gcc 2.95's docs do mention "asm volatile" having an effect on ordering, which is probably where the notion came from: "If you write an `asm' instruction with no outputs, GNU CC [...] not delete the instruction or move it outside of loops. [...] you should write the `volatile' keyword to prevent future versions of GNU CC from moving the instruction around within a core region". Lucky we never relied on that, right? Right? 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/ |