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]
Message-ID: <CALzav=eK0Dgszy4B6rkFQ+bkVyKv+E19=QFdM=6NCOsOgCuMCQ@mail.gmail.com>
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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ