x86, paravirt: Add a global synchronization point for pvclock
in [Kernel]
|
From: Peter Palfrader on 13 Jul 2010 13:00 On Tue, 13 Jul 2010, Avi Kivity wrote: >> The same: >> >> [git|v2.6.32.16] weasel(a)thelma:/scratch/kernel/2.6.32.16$ nm arch/x86/kernel/pvclock.o >> 0000000000000000 r last_value >> U native_read_tsc >> 0000000000000040 T pvclock_clocksource_read >> 0000000000000100 T pvclock_read_wallclock >> 0000000000000000 T pvclock_tsc_khz >> U set_normalized_timespec >> > > But it's > >> >> static atomic64_t last_value = ATOMIC64_INIT(0); >> > > Doesn't make any sense. > > Let's try to see if the toolchain is confused: > > - rename last_value to some random name 0000000000000000 r some_random_name > - drop the 'static' qualifier 0000000000000000 B last_value > - drop the '= ATOMIC64_INIT(0)' 0000000000000000 b last_value > - all of the above 0000000000000000 B some_random_name make -f scripts/Makefile.build obj=arch/x86/kernel arch/x86/kernel/pvclock.o gcc -Wp,-MD,arch/x86/kernel/.pvclock.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.3.2/include -Iinclude -I/scratch/kernel/2.6.32.16/arch/x86/include -include include/linux/autoconf.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -fstack-protector -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(pvclock)" -D"KBUILD_MODNAME=KBUILD_STR(pvclock)" -c -o arch/x86/kernel/pvclock.o arch/x86/kernel/pvclock.c [git|v2.6.32.16] weasel(a)thelma:/scratch/kernel/2.6.32.16$ gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Using -O0 also results in a writeable last_value (b). -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ -- 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: Peter Palfrader on 13 Jul 2010 13:30 On Tue, 13 Jul 2010, Avi Kivity wrote: > On 07/13/2010 07:40 PM, Avi Kivity wrote: >> On 07/13/2010 07:34 PM, Avi Kivity wrote: >>> >>> My bet is that dropping 'static' will fix it. We may have the wrong >>> constraints on atomic64_cmpxchg64(), so the compiler thinks we never >>> change last_value. >>> >> >> The constraints are there, but maybe the toolchain is confused. >> > > No they aren't, as Linus just pointed out. His patch should fix the > problem. Linus's patch touches __xchg() whereas we're using __cmpxchg() in this particular case I think. At least, applying it to my 2.6.32.16 tree didn't help, last_value was still read-only. Or I backported it wrong. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ -- 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: Peter Palfrader on 13 Jul 2010 14:30
On Tue, 13 Jul 2010, Linus Torvalds wrote: > On Tue, Jul 13, 2010 at 10:50 AM, Linus Torvalds > <torvalds(a)linux-foundation.org> wrote: > > > > No, you didn't back-port it wrong. I just didn't fix the right part. I > > thought the PV code used xchg, not cmpxchg, so I only patched that. > > But cmpxchg has the exact same issue. > > > > Does this fix it? It appears to, thanks a lot. [git|v2.6.32.16] weasel(a)thelma:/scratch/kernel/2.6.32.16$ nm arch/x86/kernel/pvclock.o 0000000000000000 b last_value ... And it did boot too. > 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. Without the cast gcc spews a fair amount of warnings. About four every time it hits the include file. Just for completeness' sake I attached the patch on top of 2.6.32.16 that I built with. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ |