Windows lets applications choose the frequency of the timer tick,
and in Windows 10 the maximum rate was changed from 1024 Hz to
2048 Hz. Unfortunately, because of the way the Windows API
works, most applications who need a higher rate than the default
64 Hz will just do
timeGetDevCaps(&tc, sizeof(tc));
timeBeginPeriod(tc.wPeriodMin);
and pick the maximum rate. This causes very high CPU usage when
playing media or games on Windows 10, even if the guest does not
actually use the CPU very much, because the frequent timer tick
causes halt_poll_ns to kick in.
There is no really good solution, especially because Microsoft
could sooner or later bump the limit to 4096 Hz, but for now
the best we can do is lower a bit the upper limit for
halt_poll_ns. :-(
Reported-by: Jon Panozzo <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
---
arch/x86/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f62a9f37f79f..b7e394485a5f 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -43,7 +43,7 @@
#define KVM_PIO_PAGE_OFFSET 1
#define KVM_COALESCED_MMIO_PAGE_OFFSET 2
-#define KVM_HALT_POLL_NS_DEFAULT 500000
+#define KVM_HALT_POLL_NS_DEFAULT 400000
#define KVM_IRQCHIP_NUM_PINS KVM_IOAPIC_NUM_PINS
--
1.8.3.1
On Tue, Mar 29, 2016 at 8:57 AM, Paolo Bonzini <[email protected]> wrote:
>
> Windows lets applications choose the frequency of the timer tick,
> and in Windows 10 the maximum rate was changed from 1024 Hz to
> 2048 Hz. Unfortunately, because of the way the Windows API
> works, most applications who need a higher rate than the default
> 64 Hz will just do
>
> timeGetDevCaps(&tc, sizeof(tc));
> timeBeginPeriod(tc.wPeriodMin);
>
> and pick the maximum rate. This causes very high CPU usage when
> playing media or games on Windows 10, even if the guest does not
> actually use the CPU very much, because the frequent timer tick
> causes halt_poll_ns to kick in.
>
> There is no really good solution, especially because Microsoft
> could sooner or later bump the limit to 4096 Hz, but for now
> the best we can do is lower a bit the upper limit for
> halt_poll_ns. :-(
This is a good solution for now. I don't think we lose noticeable
performance by lowering the max to 400 us.
Do you think it's ever useful to poll for a timer interrupt? It seems
like it wouldn't be. We don't need polling to deliver accurate timer
interrupts, KVM already delivers the TSC deadline timer slightly early
to account for injection delay. Maybe we can shrink polling anytime a
timer interrupt wakes up a VCPU.
>
> Reported-by: Jon Panozzo <[email protected]>
> Signed-off-by: Paolo Bonzini <[email protected]>
> ---
> arch/x86/include/asm/kvm_host.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index f62a9f37f79f..b7e394485a5f 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -43,7 +43,7 @@
>
> #define KVM_PIO_PAGE_OFFSET 1
> #define KVM_COALESCED_MMIO_PAGE_OFFSET 2
> -#define KVM_HALT_POLL_NS_DEFAULT 500000
> +#define KVM_HALT_POLL_NS_DEFAULT 400000
>
> #define KVM_IRQCHIP_NUM_PINS KVM_IOAPIC_NUM_PINS
>
> --
> 1.8.3.1
>
On 29/03/2016 19:16, David Matlack wrote:
> On Tue, Mar 29, 2016 at 8:57 AM, Paolo Bonzini <[email protected]> wrote:
>>
>> Windows lets applications choose the frequency of the timer tick,
>> and in Windows 10 the maximum rate was changed from 1024 Hz to
>> 2048 Hz. Unfortunately, because of the way the Windows API
>> works, most applications who need a higher rate than the default
>> 64 Hz will just do
>>
>> timeGetDevCaps(&tc, sizeof(tc));
>> timeBeginPeriod(tc.wPeriodMin);
>>
>> and pick the maximum rate. This causes very high CPU usage when
>> playing media or games on Windows 10, even if the guest does not
>> actually use the CPU very much, because the frequent timer tick
>> causes halt_poll_ns to kick in.
>>
>> There is no really good solution, especially because Microsoft
>> could sooner or later bump the limit to 4096 Hz, but for now
>> the best we can do is lower a bit the upper limit for
>> halt_poll_ns. :-(
>
> This is a good solution for now. I don't think we lose noticeable
> performance by lowering the max to 400 us.
Good, then I'll submit it for 4.6 and applicable stable kernels.
> Do you think it's ever useful to poll for a timer interrupt? It seems
> like it wouldn't be. We don't need polling to deliver accurate timer
> interrupts, KVM already delivers the TSC deadline timer slightly early
> to account for injection delay. Maybe we can shrink polling anytime a
> timer interrupt wakes up a VCPU.
That's a clever idea. Because this really applies only to Windows we
can just extend the special casing of GSI 8 (the RTC GSI), which exists
exactly because Windows uses it as a periodic interrupt timer.
On the other hand, that wouldn't work for split irqchip. For that you
would probably add a new "no polling required" flag to struct
kvm_irq_routing_entry, but finding a suitable place to call
shrink_halt_poll_ns might be a bit hackish.
Paolo
>>
>> Reported-by: Jon Panozzo <[email protected]>
>> Signed-off-by: Paolo Bonzini <[email protected]>
>> ---
>> arch/x86/include/asm/kvm_host.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>> index f62a9f37f79f..b7e394485a5f 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -43,7 +43,7 @@
>>
>> #define KVM_PIO_PAGE_OFFSET 1
>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 2
>> -#define KVM_HALT_POLL_NS_DEFAULT 500000
>> +#define KVM_HALT_POLL_NS_DEFAULT 400000
>>
>> #define KVM_IRQCHIP_NUM_PINS KVM_IOAPIC_NUM_PINS
>>
>> --
>> 1.8.3.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>