From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
"Wu, Feng" <feng.wu@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Alexander Yarygin <yarygin@linux.vnet.ibm.com>
Subject: Re: A question about HTL VM-Exit handling time
Date: Tue, 28 Oct 2014 08:46:50 +0100 [thread overview]
Message-ID: <544F49EA.1090805@de.ibm.com> (raw)
In-Reply-To: <5446A875.4080204@redhat.com>
Am 21.10.2014 20:39, schrieb Paolo Bonzini:
>
>
> On 10/16/2014 10:15 AM, Wu, Feng wrote:
>> Hi folks,
>>
>> I run kernel build in the guest and use perf kvm to get some VM-Exit result as the following:
>>
>> Analyze events for all VCPUs:
>>
>> VM-EXIT Samples Samples% Time% Min Time Max Time A
>>
>> MSR_WRITE 3613908 57.53% 18.97% 5us 1362us 9.73
>> HLT 1399747 22.28% 74.90% 5us 432448us 99.24
>> CR_ACCESS 961203 15.30% 3.28% 4us 188us 6.33
>> EXTERNAL_INTERRUPT 213821 3.40% 2.25% 4us 4089us 19.54
>> EXCEPTION_NMI 25152 0.40% 0.12% 4us 71us 9.05
>> EPT_MISCONFIG 20104 0.32% 0.15% 8us 5628us 13.74
>> CPUID 19904 0.32% 0.07% 4us 220us 6.90
>> IO_INSTRUCTION 17097 0.27% 0.20% 13us 1008us 22.08
>> PAUSE_INSTRUCTION 10737 0.17% 0.05% 4us 53us 8.33
>> MSR_READ 48 0.00% 0.00% 4us 8us 5.62
>>
>> Total Samples:6281721, Total events handled time:185457820.41us.
>>
>> I also do some other experiments with different workload in the guest, I got the same results in terms of
>> HLT VM-Exit handling time. Does anyone know why the handling time for HLT VM-Exit is so high? Appreciate
>> You help!
>
> 432 ms sounds like a lot, but in general it is expected that HLT vmexits
> take a long time. After an HLT vmexit, the VCPU will not be reentered
> until the next interrupt comes. On hardware, the HLT instruction can
> also take many milliseconds.
>
> If this is an SMP guest, it's possible that the maximum time is
> registered on the APs before Linux boots. With a UP guest I would
> expect a shorter maximum time, but still longer than other vmexits.
We have the same on s390 with wait state. The thing is, with an idle system and NOHZ the time spend in HLT/wait could be really long. So We might want to provide an option to filter this out.
(A similar filter already exitis for the --duration option)
prev parent reply other threads:[~2014-10-28 7:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 8:15 A question about HTL VM-Exit handling time Wu, Feng
2014-10-21 18:39 ` Paolo Bonzini
2014-10-23 4:56 ` Wu, Feng
2014-10-23 12:23 ` Paolo Bonzini
2014-10-24 1:14 ` Wu, Feng
2014-10-27 23:52 ` Wanpeng Li
2014-10-28 10:16 ` Paolo Bonzini
2014-10-28 7:46 ` Christian Borntraeger [this message]
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=544F49EA.1090805@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=feng.wu@intel.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=xiaoguangrong.eric@gmail.com \
--cc=yarygin@linux.vnet.ibm.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.