From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <kernellwp@gmail.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: "Wanpeng Li" <wanpeng.li@hotmail.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"David Matlack" <dmatlack@google.com>
Subject: Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon
Date: Thu, 19 May 2016 17:42:11 +0200 [thread overview]
Message-ID: <573DDED3.4090503@de.ibm.com> (raw)
In-Reply-To: <83e82f6b-bc6b-a85b-e2c7-9a1b4d4997d1@redhat.com>
On 05/19/2016 05:06 PM, Paolo Bonzini wrote:
>
>
> On 19/05/2016 17:03, Christian Borntraeger wrote:
>>>> Would this work too and be simpler?
>>>> Hmm, your patch does only fiddle with the grow/shrink logic (which might
>>>> be a good idea independently of this change), but the original patch
>>>> actually takes into account that we have a guaranteed maximum time by a
>>>> wakeup timer - IOW we know exactly what the maximum poll time is.
>>>
>>> Yes, it's different. The question is whether a 10us poll (40,000 clock
>>> cycles) has an impact even if it's sometimes wrong.
>>
>> Valid question. As I said, this change might be something good independent from
>> the original patch. (it might make it unnecessary, though) On the other hand
>> I can handle ~30 guest entry/exit cycles of a simple exit like diag9c.
>> Needs measurement.
>
> Actually I'm okay with the original patch, and especially on s390 where
> the maximum poll time is small it may make a bigger difference. Though
> I suppose the timer interrupt is not floating?
Right its cpu local. So a timer wakeup would be considered valid (if the timer
kicks in before the poll ends - the poll does also check if the timer expires and
maybe the hrtimer is a bit late.
>
> Since it's not 4.7 material, I'll wait for your experiments and David's
> remarks.
I will try to get both patches scheduled but it might take a while.
next prev parent reply other threads:[~2016-05-19 15:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 13:27 [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon Wanpeng Li
2016-05-19 13:46 ` Christian Borntraeger
2016-05-19 13:57 ` Paolo Bonzini
2016-05-19 14:52 ` Christian Borntraeger
2016-05-19 14:56 ` Paolo Bonzini
2016-05-19 15:03 ` Christian Borntraeger
2016-05-19 15:06 ` Paolo Bonzini
2016-05-19 15:42 ` Christian Borntraeger [this message]
2016-05-24 2:48 ` Wanpeng Li
2016-05-19 18:01 ` David Matlack
2016-05-19 18:36 ` David Matlack
2016-05-20 2:04 ` Yang Zhang
2016-05-20 5:53 ` Wanpeng Li
2016-05-20 18:37 ` David Matlack
2016-05-23 1:26 ` Yang Zhang
2016-05-23 18:04 ` David Matlack
2016-05-24 1:13 ` Yang Zhang
2016-05-24 1:16 ` David Matlack
2016-05-24 2:55 ` Yang Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=573DDED3.4090503@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=dmatlack@google.com \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=wanpeng.li@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.