Add a global synchronization point for pvclock
in [Kernel]
|
Prev: Sound not transferred to docking station after resume from StR
Next: Process-shared futexes on hugepages puts the kernel in an infinite loop in 2.6.32.11; is this fixed now?
From: Jeremy Fitzhardinge on 20 Apr 2010 14:30 On 04/20/2010 02:31 AM, Avi Kivity wrote: > btw, do you want this code in pvclock.c, or shall we keep it kvmclock > specific? I think its a pvclock-level fix. I'd been hoping to avoid having something like this, but I think its ultimately necessary. 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: Peter Zijlstra on 19 Apr 2010 06:40 On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote: > > + do { > > + last = last_value; > > > Does this need a barrier() to prevent the compiler from re-reading > last_value for the subsequent lines? Otherwise "(ret < last)" and > "return last" could execute with different values for "last". > ACCESS_ONCE() is your friend. -- 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 Zijlstra on 19 Apr 2010 06:50 On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote: > > After this patch is applied, I don't see a single warp in time during 5 days > > of execution, in any of the machines I saw them before. > > > > > > Please define a cpuid bit that makes this optional. When we eventually > enable it in the future, it will allow a wider range of guests to enjoy it. Right, so on x86 we have: X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency independent, not that it doesn't stop in C states and similar fun stuff. X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant and synced between cores. -- 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: Avi Kivity on 19 Apr 2010 06:50 On 04/19/2010 01:43 PM, Peter Zijlstra wrote: > >>> >>>> + >>>> cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src) >>>> { >>>> struct pvclock_shadow_time shadow; >>>> unsigned version; >>>> cycle_t ret, offset; >>>> + u64 last; >>>> >>>> >>>> + do { >>>> + last = last_value; >>>> >>> Otherwise, this assignment can see a partial update. >>> >> On a 32-bit guest, that is. >> > Right, do bear in mind that the x86 implementation of atomic64_read() is > terrifyingly expensive, it is better to not do that read and simply use > the result of the cmpxchg. > > atomic64_read() _is_ cmpxchg64b. Are you thinking of some clever implementation for smp i386? -- error compiling committee.c: too many arguments to function -- 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: Avi Kivity on 19 Apr 2010 06:50
On 04/19/2010 01:46 PM, Peter Zijlstra wrote: > On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote: > >>> After this patch is applied, I don't see a single warp in time during 5 days >>> of execution, in any of the machines I saw them before. >>> >>> >>> >> Please define a cpuid bit that makes this optional. When we eventually >> enable it in the future, it will allow a wider range of guests to enjoy it. >> > Right, so on x86 we have: > > X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency > independent, not that it doesn't stop in C states and similar fun stuff. > > X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant > and synced between cores. > > Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)? -- error compiling committee.c: too many arguments to function -- 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/ |