From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Subject: Re: [PATCH 1/1] KVM: halt_polling: provide a way to qualify wakeups
 during poll
Date: Wed, 4 May 2016 10:05:45 +0200
Message-ID: <20160504100545.090be51b.cornelia.huck@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Radim =?UTF-8?B?S3LEjW3DocWZ?= <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: Christian Borntraeger <borntraeger@de.ibm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from e06smtp07.uk.ibm.com ([195.75.94.103]:36051 "EHLO
	e06smtp07.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757252AbcEDIF6 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 4 May 2016 04:05:58 -0400
Received: from localhost
	by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
	for <kvm@vger.kernel.org> from <cornelia.huck@de.ibm.com>;
	Wed, 4 May 2016 09:05:56 +0100
In-Reply-To: <5729A9E1.3050706@de.ibm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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)) {