aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/futex-contention.py
diff options
context:
space:
mode:
authorRadim Krčmář <[email protected]>2015-09-18 17:54:29 +0200
committerPaolo Bonzini <[email protected]>2015-10-01 15:06:42 +0200
commit72c930dcfc2b49404ee9e20f6c868402e9c71166 (patch)
tree83ff98a7c359fef9f294bbca18529bca8caf7a27 /tools/perf/scripts/python/futex-contention.py
parent1cea0ce68ed76490ffa64a9e2a7a40104efe9352 (diff)
x86: kvmclock: abolish PVCLOCK_COUNTS_FROM_ZERO
Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore. The purpose of that flags was to start counting system time from 0 when the KVM clock has been initialized. We can achieve the same by selecting one read as the initial point. A simple subtraction will work unless the KVM clock count overflows earlier (has smaller width) than scheduler's cycle count. We should be safe till x86_128. Because PVCLOCK_COUNTS_FROM_ZERO was enabled only on new hypervisors, setting sched clock as stable based on PVCLOCK_TSC_STABLE_BIT might regress on older ones. I presume we don't need to change kvm_clock_read instead of introducing kvm_sched_clock_read. A problem could arise in case sched_clock is expected to return the same value as get_cycles, but we should have merged those clocks in that case. Signed-off-by: Radim Krčmář <[email protected]> Acked-by: Marcelo Tosatti <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/futex-contention.py')
0 files changed, 0 insertions, 0 deletions