From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755116AbcESN5r (ORCPT ); Thu, 19 May 2016 09:57:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57131 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755050AbcESN5q (ORCPT ); Thu, 19 May 2016 09:57:46 -0400 Subject: Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon To: Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org References: <1463664426-2991-1-git-send-email-wanpeng.li@hotmail.com> Cc: Wanpeng Li , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , David Matlack , Christian Borntraeger From: Paolo Bonzini Message-ID: <19abf5c8-7016-45af-f0e6-3bdd161ffb38@redhat.com> Date: Thu, 19 May 2016 15:57:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463664426-2991-1-git-send-email-wanpeng.li@hotmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 19 May 2016 13:57:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19/05/2016 15:27, Wanpeng Li wrote: > From: Wanpeng Li > > If an emulated lapic timer will fire soon(in the scope of 10us the > base of dynamic halt-polling, lower-end of message passing workload > latency TCP_RR's poll time < 10us) we can treat it as a short halt, > and poll to wait it fire, the fire callback apic_timer_fn() will set > KVM_REQ_PENDING_TIMER, and this flag will be check during busy poll. > This can avoid context switch overhead and the latency which we wake > up vCPU. Would this work too and be simpler? diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 4fd482fb9260..8d42f5304d94 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1964,16 +1964,12 @@ static void grow_halt_poll_ns(struct kvm_vcpu *vcpu) old = val = vcpu->halt_poll_ns; grow = READ_ONCE(halt_poll_ns_grow); - /* 10us base */ - if (val == 0 && grow) - val = 10000; - else - val *= grow; + val *= grow; if (val > halt_poll_ns) val = halt_poll_ns; - vcpu->halt_poll_ns = val; + vcpu->halt_poll_ns = max(10000u, val); trace_kvm_halt_poll_ns_grow(vcpu->vcpu_id, val, old); } @@ -1988,7 +1984,7 @@ static void shrink_halt_poll_ns(struct kvm_vcpu *vcpu) else val /= shrink; - vcpu->halt_poll_ns = val; + vcpu->halt_poll_ns = max(10000u, val); trace_kvm_halt_poll_ns_shrink(vcpu->vcpu_id, val, old); } (Plus moving 10000 into a module parameter?) Can you measure higher CPU utilization than with your patch? David, what do you think? Thanks, Paolo