aboutsummaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/lists.py
diff options
context:
space:
mode:
authorPeter Zijlstra <[email protected]>2017-03-01 15:53:38 +0100
committerIngo Molnar <[email protected]>2017-03-02 08:50:49 +0100
commitf94c8d116997597fc00f0812b0ab9256e7b0c58f (patch)
tree9f2ea53d8def1a466727bcd9768e220ea7fb1164 /scripts/gdb/linux/lists.py
parent0ba87bb27d66b78e278167ac7e20c66520b8a612 (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