sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface
authorPeter Zijlstra <peterz@infradead.org>
Wed, 1 Mar 2017 14:53:38 +0000 (15:53 +0100)
committerIngo Molnar <mingo@kernel.org>
Thu, 2 Mar 2017 07:50:49 +0000 (08:50 +0100)
commitf94c8d116997597fc00f0812b0ab9256e7b0c58f
tree9f2ea53d8def1a466727bcd9768e220ea7fb1164
parent0ba87bb27d66b78e278167ac7e20c66520b8a612
sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface

Wanpeng Li reported that since the following commit:

  acb04058de49 ("sched/clock: Fix hotplug crash")

... KVM always runs with unstable sched-clock even though KVM's
kvm_clock _is_ stable.

The problem is that we've tied clear_sched_clock_stable() to the TSC
state, and overlooked that sched_clock() is a paravirt function.

Solve this by doing two things:

 - tie the sched_clock() stable state more clearly to the TSC stable
   state for the normal (!paravirt) case.

 - only call clear_sched_clock_stable() when we mark TSC unstable
   when we use native_sched_clock().

The first means we can actually run with stable sched_clock in more
situations then before, which is good. And since commit:

  12907fbb1a69 ("sched/clock, clocksource: Add optional cs::mark_unstable() method")

... this should be reliable. Since any detection of TSC fail now results
in marking the TSC unstable.

Reported-by: Wanpeng Li <kernellwp@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: acb04058de49 ("sched/clock: Fix hotplug crash")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
arch/x86/kernel/cpu/amd.c
arch/x86/kernel/cpu/centaur.c
arch/x86/kernel/cpu/common.c
arch/x86/kernel/cpu/cyrix.c
arch/x86/kernel/cpu/intel.c
arch/x86/kernel/cpu/transmeta.c
arch/x86/kernel/tsc.c