>>> On 22.06.15 at 04:48, wrote:
> We found that all the events are HVM_EMUL_LAPIC_START_TIMER. The number of
> TRC_HVM_EMUL_LAPIC_STOP_TIMER event is zero.
>
> Below is the details:
>
> apicv on:
> TRC_HVM_EMUL_LAPIC_START_TIMER: count=111480
> TRC_HVM_EMUL_LAPIC_STOP_TIMER: count=0
> apicv of
); Huangpeng (Peter); Xuzhichuang; yang.z.zh...@intel.com;
xen-devel@lists.xen.org
Subject: RE: [Xen-devel] performace issue when turn on apicv
>>> On 18.06.15 at 16:55, wrote:
> I'm John's colleague. We looked into the details of the tracing data,
> and
On Thu, Jun 18, 2015 at 10:35:37AM +0100, Jan Beulich wrote:
> >>> On 18.06.15 at 11:18, wrote:
> > Jan Beulich wrote on 2015-06-18:
> > On 18.06.15 at 10:53, wrote:
> >>> Jan Beulich wrote on 2015-06-18:
> >>> On 18.06.15 at 10:20, wrote:
> > Apart from that I notice that the EXIT_R
>>> On 18.06.15 at 16:55, wrote:
> I'm John's colleague. We looked into the details of the tracing data, and
> found that the number of MSR_IA32_APICTMICT_MSR
> event is quite high when apic-v is enabled(about 9x more compared with apic-v
> disabled).
>
> Below is the details:
>
> EXIT_REASON_
Yang Z Zhang ,
"xen-de...@lists.xensource.com" ,
"peter.huangp...@huawei.com"
Subject: Re: [Xen-devel] performace issue when turn on apicv
Message-ID: <55829b77027800086...@mail.emea.novell.com>
Content-Type: text/plain; charset=US-ASCII
>>> On 18.06.15 a
>>> On 18.06.15 at 11:18, wrote:
> Jan Beulich wrote on 2015-06-18:
> On 18.06.15 at 10:53, wrote:
>>> Jan Beulich wrote on 2015-06-18:
>>> On 18.06.15 at 10:20, wrote:
> Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
> also adds about the same number of ticks
Jan Beulich wrote on 2015-06-18:
On 18.06.15 at 10:02, wrote:
>> When using FIO to test the performance of SSD passthroughed in vm
>> the result show that: When the apicv is on, each
>> EXIT_REASON_MSR_WRITE event spent more time than apicv is off.
>>
>> Following is the xentrace result:
>>
Jan Beulich wrote on 2015-06-18:
On 18.06.15 at 10:53, wrote:
>> Jan Beulich wrote on 2015-06-18:
>> On 18.06.15 at 10:20, wrote:
Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
also adds about the same number of ticks...
>>>
>>> Are there any other devices
>>> On 18.06.15 at 10:53, wrote:
> Jan Beulich wrote on 2015-06-18:
> On 18.06.15 at 10:20, wrote:
>>> Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
>>> also adds about the same number of ticks...
>>
>> Are there any other devices in the guest causing meaningful amounts
Jan Beulich wrote on 2015-06-18:
On 18.06.15 at 10:20, wrote:
>> Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
>> also adds about the same number of ticks...
>
> Are there any other devices in the guest causing meaningful amounts of
> interrupts (I suppose the SSD itself
>>> On 18.06.15 at 10:20, wrote:
> Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
> also adds about the same number of ticks...
Are there any other devices in the guest causing meaningful amounts
of interrupts (I suppose the SSD itself is using just one)? I ask since I
wonder
>>> On 18.06.15 at 10:02, wrote:
> When using FIO to test the performance of SSD passthroughed in vm the
> result show that: When the apicv is on, each EXIT_REASON_MSR_WRITE event
> spent more time than apicv is off.
>
> Following is the xentrace result:
>
> apicv on:
>
>VMExitCode
Hi,
We have test on upstream Xen, it seem the upstream version also has the same
problem.
When using FIO to test the performance of SSD passthroughed in vm the result
show that: When the apicv is on, each EXIT_REASON_MSR_WRITE event spent more
time than apicv is off.
Following is the xentra
Liuqiming (John) wrote on 2015-06-11:
> I will setup a test environment for xen upstream version but need some time.
> Meanwhile, can you give me some idea about what MAY cause this problem?
How you set the irq affinity of assigned SSD device? IIRC, the irq is migrated
with vcpu by default in cur
I will setup a test environment for xen upstream version but need some time.
Meanwhile, can you give me some idea about what MAY cause this problem?
I have been using xentrace to trace the problem, from what I see, the apicv
feature
itself works
apicv=1
2583096 VMEXIT 1902
Liuqiming (John) wrote on 2015-06-11:
> Hi,
>
> Recently I encounter a strange performance problem with APIC virtualization.
>
> My host has Intel(R) Xeon(R) CPU E7-4890 v2 CPU installed which support
> APIC virtualization and x2apic, and there are 4 socket * 15
> cores_per_socket = 60 core avail
Hi,
Recently I encounter a strange performance problem with APIC virtualization.
My host has Intel(R) Xeon(R) CPU E7-4890 v2 CPU installed which support
APIC virtualization and x2apic, and there are 4 socket * 15
cores_per_socket = 60 core available for VM. There is also a SSD disk on
host an
17 matches
Mail list logo
