From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: performace issue when turn on apicv
Date: Fri, 19 Jun 2015 10:23:00 -0400
Message-ID: <20150619142300.GK21541@l.oracle.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E0AD018A1@SHSMSX104.ccr.corp.intel.com>
	<55794247.1010100@huawei.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0AD01A46@SHSMSX104.ccr.corp.intel.com>
	<55827B07.4000304@huawei.com>
	<55829B770200007800086752@mail.emea.novell.com>
	<5582A2D60200007800086794@mail.emea.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0AD0AEFD@SHSMSX104.ccr.corp.intel.com>
	<5582A85C02000078000867F2@mail.emea.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E0AD0AFB2@SHSMSX104.ccr.corp.intel.com>
	<5582AD090200007800086884@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <5582AD090200007800086884@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, "Liuqiming (John)" <john.liuqiming@huawei.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "peter.huangpeng@huawei.com" <peter.huangpeng@huawei.com>
List-Id: xen-devel@lists.xenproject.org

On Thu, Jun 18, 2015 at 10:35:37AM +0100, Jan Beulich wrote:
> >>> On 18.06.15 at 11:18, <yang.z.zhang@intel.com> wrote:
> > Jan Beulich wrote on 2015-06-18:
> >>>>> On 18.06.15 at 10:53, <yang.z.zhang@intel.com> wrote:
> >>> Jan Beulich wrote on 2015-06-18:
> >>>>>>> On 18.06.15 at 10:20, <JBeulich@suse.com> 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 whether e.g. there may be lock contention in
> >> vioapic_update_EOI().
> >>> 
> >>> The EXIT_REASON_EOI_INDUCED is for local apic time.
> >> 
> >> ??? (I.e. I don't see the connection between the context and your reply.
> >> Perhaps I'm missing something obvious...)
> > 
> > I mean the lots of EXIT_REASON_EOI_INDUCEDis for local apic time which is 
> > edge-trigger. So it will not call vioapic_update_EOI.
> 
> Okay, this then suggests the problem being hvm_dpci_msi_eoi(),
> albeit looking at it I can't immediately see why it would take long.

We do take two spin-locks (d->event_lock) and (desc->lock) and also
can IPI set_eoi_ready across different CPUs.

Perhaps it might be worth adding some TRACE with the time taken
to get the locks and also doing the IPIs?

> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel