From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [PATCH 1/1] KVM: halt_polling: provide a way to qualify wakeups
 during poll
Date: Fri, 13 May 2016 12:18:44 +0200
Message-ID: <5735AA04.2080400@de.ibm.com>
References: <1462279041-17028-1-git-send-email-borntraeger@de.ibm.com>
 <1462279041-17028-2-git-send-email-borntraeger@de.ibm.com>
 <20160503150902.GF30059@potion> <5729A9E1.3050706@de.ibm.com>
 <20160504100545.090be51b.cornelia.huck@de.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Jens Freimann <jfrei@linux.vnet.ibm.com>,
	David Hildenbrand <dahi@linux.vnet.ibm.com>,
	Wanpeng Li <kernellwp@gmail.com>,
	David Matlack <dmatlack@google.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:50840 "EHLO
	e06smtp14.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751280AbcEMKSu (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 13 May 2016 06:18:50 -0400
Received: from localhost
	by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <borntraeger@de.ibm.com>;
	Fri, 13 May 2016 11:18:49 +0100
In-Reply-To: <20160504100545.090be51b.cornelia.huck@de.ibm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 05/04/2016 10:05 AM, Cornelia Huck wrote:
> On Wed, 4 May 2016 09:50:57 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> 
>> The feedback about the logic triggered some more experiments on my side.
>> So I was experimenting with some different workloads/heuristics and it
>> seems that even more aggressive shrinking (basically resetting to 0 as soon
>> as an invalid poll comes along) does improve the cpu usage even more.
> 
> Do we still keep the shrink instead of resetting to 0 explicitly? (In
> case the default shrink factor was set to != 0.) We'd lose a tuneable,
> but it seems the aggressiveness is warranted.
> 
>> (So the new diff looks like)
>> @@ -2034,7 +2036,9 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
>>  out:
>>         block_ns = ktime_to_ns(cur) - ktime_to_ns(start);
>>
>> -       if (halt_poll_ns) {
>> +       if (!vcpu_valid_wakeup(vcpu))
>> +                shrink_halt_poll_ns(vcpu);
>> +       else if (halt_poll_ns) {
>>                 if (block_ns <= vcpu->halt_poll_ns)
>>                         ;
> 
> ...making this
> 
> if (halt_poll_ns && vcpu_valid_wakeup(vcpu)) {
> 

I decided to keep my version as it should be functionally equivalent for shrink==0
but it allows the performance folks to do future testing for better heuristics.

David, Wanpeng,
I just send out the patch set but I forgot to Cc you :-/




Christian