search for: sched_clock

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we:...

Subject: Add a sched_clock paravirt_op The tsc-based get_scheduled_cycles interface is not a good match for Xen's runstate accounting, which reports everything in nanoseconds. This patch replaces this interface with a sched_clock interface, which matches both Xen and VMI's requirements. In order to do this, we:...

I just rebased my paravirt_ops patch queue to current git. Looks like almost all the pre-req patches are now in, which is nice. The only missing thing from your patches was you sched_clock patches and the sched_clock paravirt-op. Are there still problems with either your sched_clock patch or the paravirt patch? Should I resubmit the paravirt-sched_clock patch based on git? The only other general patches before the Xen series I have left in my queue are: i386-common-smp.patch...

I just rebased my paravirt_ops patch queue to current git. Looks like almost all the pre-req patches are now in, which is nice. The only missing thing from your patches was you sched_clock patches and the sched_clock paravirt-op. Are there still problems with either your sched_clock patch or the paravirt patch? Should I resubmit the paravirt-sched_clock patch based on git? The only other general patches before the Xen series I have left in my queue are: i386-common-smp.patch...

...ance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which is how Xen and VMI currently implement it. If the softlockup watchdog uses sched_clock() to measure time, it would automatically ignore stolen time, and therefore only report when the guest itself locked up. When running native, sched_clock() returns r...

...ance in a virtual machine, since the whole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which is how Xen and VMI currently implement it. If the softlockup watchdog uses sched_clock() to measure time, it would automatically ignore stolen time, and therefore only report when the guest itself locked up. When running native, sched_clock() returns r...

On Thu, 27 Oct 2016, Alexey Makhalov wrote: > Set pv_time_ops.sched_clock to vmware_sched_clock(). Please do not describe WHAT the patch does, describe why. Describe the problem you are solving. I can see from the patch > + pv_time_ops.sched_clock = vmware_sched_clock; that you set pv_time_ops.sched_clock to vmware_sched_clock(). > It is simplified > versi...

...ing is, if the TSC is not synced, you cannot use it for > timekeeping, full stop. So having a single page is fine, it either > contains a mult/shift that is valid, or it indicates TSC is messed up > and you fall back to something else. > > There is no inbetween there. > > For sched_clock we can still use the global page, because the rate will > still be the same for each cpu, it's just offset between CPUs and the > code compensates for that. But if we?re in a KVM guest, then the clock will jump around on the same *vCPU* when the vCPU migrates. But I don?t see how kvmclo...

...ing is, if the TSC is not synced, you cannot use it for > timekeeping, full stop. So having a single page is fine, it either > contains a mult/shift that is valid, or it indicates TSC is messed up > and you fall back to something else. > > There is no inbetween there. > > For sched_clock we can still use the global page, because the rate will > still be the same for each cpu, it's just offset between CPUs and the > code compensates for that. But if we?re in a KVM guest, then the clock will jump around on the same *vCPU* when the vCPU migrates. But I don?t see how kvmclo...

...iption+0xea/0x380 [ 46.166701] ? virtnet_poll+0xd9c/0xfd1 [virtio_net] [ 46.166711] kasan_report+0x1dd/0x460 [ 46.166727] ? virtnet_poll+0xd9c/0xfd1 [virtio_net] [ 46.166743] virtnet_poll+0xd9c/0xfd1 [virtio_net] [ 46.166767] ? receive_buf+0x2e30/0x2e30 [virtio_net] [ 46.166796] ? sched_clock_cpu+0x18/0x2b0 [ 46.166809] ? print_irqtrace_events+0x280/0x280 [ 46.166817] ? print_irqtrace_events+0x280/0x280 [ 46.166830] ? rcu_process_callbacks+0xc5e/0x12d0 [ 46.166838] ? kvm_clock_read+0x1f/0x30 [ 46.166857] ? mark_held_locks+0xd5/0x170 [ 46.166867] ? net_rx_action+0x2aa/0...

...iption+0xea/0x380 [ 46.166701] ? virtnet_poll+0xd9c/0xfd1 [virtio_net] [ 46.166711] kasan_report+0x1dd/0x460 [ 46.166727] ? virtnet_poll+0xd9c/0xfd1 [virtio_net] [ 46.166743] virtnet_poll+0xd9c/0xfd1 [virtio_net] [ 46.166767] ? receive_buf+0x2e30/0x2e30 [virtio_net] [ 46.166796] ? sched_clock_cpu+0x18/0x2b0 [ 46.166809] ? print_irqtrace_events+0x280/0x280 [ 46.166817] ? print_irqtrace_events+0x280/0x280 [ 46.166830] ? rcu_process_callbacks+0xc5e/0x12d0 [ 46.166838] ? kvm_clock_read+0x1f/0x30 [ 46.166857] ? mark_held_locks+0xd5/0x170 [ 46.166867] ? net_rx_action+0x2aa/0...

Hello, This series of patches integrates msr.h header. What it really does, is a series of steps to allow us to get rid of duplicate code between i386 and x86_64 versions With this done, achieving paravirt for x86_64 gets really easy, just a couple of extra code. The first patch was already sent a while ago, but was not yet pushed to any tree , to my knowledge. So it is sent again. Also,

Hello, This series of patches integrates msr.h header. What it really does, is a series of steps to allow us to get rid of duplicate code between i386 and x86_64 versions With this done, achieving paravirt for x86_64 gets really easy, just a couple of extra code. The first patch was already sent a while ago, but was not yet pushed to any tree , to my knowledge. So it is sent again. Also,

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the CPU goes into a (potentially unbounded...

Here's couple of patches to improve the softlockup watchdog. The first changes the softlockup timer from using jiffies to sched_clock() as a timebase. Xen and VMI implement sched_clock() as counting unstolen time, so time stolen by the hypervisor won't cause the watchdog to bite. The second adds per-cpu enable flags for the watchdog timer. This allows the timer to be disabled when the CPU goes into a (potentially unbounded...

...166701]? ? virtnet_poll+0xd9c/0xfd1 [virtio_net] > [?? 46.166711]? kasan_report+0x1dd/0x460 > [?? 46.166727]? ? virtnet_poll+0xd9c/0xfd1 [virtio_net] > [?? 46.166743]? virtnet_poll+0xd9c/0xfd1 [virtio_net] > [?? 46.166767]? ? receive_buf+0x2e30/0x2e30 [virtio_net] > [?? 46.166796]? ? sched_clock_cpu+0x18/0x2b0 > [?? 46.166809]? ? print_irqtrace_events+0x280/0x280 > [?? 46.166817]? ? print_irqtrace_events+0x280/0x280 > [?? 46.166830]? ? rcu_process_callbacks+0xc5e/0x12d0 > [?? 46.166838]? ? kvm_clock_read+0x1f/0x30 > [?? 46.166857]? ? mark_held_locks+0xd5/0x170 > [?? 46.16...

...rovements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time, so use that as the timebase for the softlockup watchdog. This also removes a dependency on jiffies. 2. Add a per-cpu enable flag for the watchdog When the scheduler disables ticks for a specific CPU, this allows the watchdog to be disabled as well. This avoids spuri...

...rovements to the softlockup watchdog and its users. They are: 1. Make the watchdog ignore stolen time When running under a hypervisor, the kernel may lose an arbitrary amount of time as "stolen time". This may cause the softlockup watchdog to trigger spruiously. Xen and VMI implement sched_clock() as measuring unstolen time, so use that as the timebase for the softlockup watchdog. This also removes a dependency on jiffies. 2. Add a per-cpu enable flag for the watchdog When the scheduler disables ticks for a specific CPU, this allows the watchdog to be disabled as well. This avoids spuri...

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz =

After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz =