diff options
author | Peter Zijlstra <[email protected]> | 2017-03-01 15:53:38 +0100 |
---|---|---|
committer | Ingo Molnar <[email protected]> | 2017-03-02 08:50:49 +0100 |
commit | f94c8d116997597fc00f0812b0ab9256e7b0c58f (patch) | |
tree | 9f2ea53d8def1a466727bcd9768e220ea7fb1164 /scripts/gdb/linux/lists.py | |
parent | 0ba87bb27d66b78e278167ac7e20c66520b8a612 (diff) |
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 <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Fixes: acb04058de49 ("sched/clock: Fix hotplug crash")
Signed-off-by: Ingo Molnar <[email protected]>
Diffstat (limited to 'scripts/gdb/linux/lists.py')
0 files changed, 0 insertions, 0 deletions