linux-kernel - Re: [PATCH] KVM: x86: reduce default value of halt_poll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Mar 2016 10:16:20 -0700
From:	David Matlack <dmatlack@...gle.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kvm list <kvm@...r.kernel.org>
Subject: Re: [PATCH] KVM: x86: reduce default value of halt_poll_ns parameter

On Tue, Mar 29, 2016 at 8:57 AM, Paolo Bonzini <pbonzini@...hat.com> 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 <jonp@...e-technology.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---
>  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
>