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 for Android: free password hash cracker in your pocket

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

Message-ID: <56FBC443.306@redhat.com>
Date:	Wed, 30 Mar 2016 14:19:15 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	David Matlack <dmatlack@...gle.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 29/03/2016 19:16, David Matlack wrote:
> 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.

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 <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
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>