From patchwork Fri Feb 10 00:54:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 9565721 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 75785601E9 for ; Fri, 10 Feb 2017 00:57:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 637FB284C2 for ; Fri, 10 Feb 2017 00:57:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5811E284D8; Fri, 10 Feb 2017 00:57:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D6B05284C2 for ; Fri, 10 Feb 2017 00:57:27 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbzU5-0005AS-NP; Fri, 10 Feb 2017 00:54:45 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbzU5-0005AM-5w for xen-devel@lists.xen.org; Fri, 10 Feb 2017 00:54:45 +0000 Received: from [193.109.254.147] by server-10.bemta-6.messagelabs.com id 90/7C-13192-45F0D985; Fri, 10 Feb 2017 00:54:44 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRWlGSWpSXmKPExsVybKJsh24w/9w Ig9mNyhZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8bn13fZCx7bVbzf+p+pgXGpRRcjF4eQwFRG iT3d59m6GDmBnNlMEl0fY0BsFgEtiRVzfjOC2GwChhJ/n2wCquHgkACyl3zmAAmLCEhLXPt8m RFkDrNAB6PEvbeTWEASwgJmEguWdILZvALeEstn7GcCsUUFdCUO/fvDBhEXlDg58wlYDbOAn0 TfxVfMELa3xP87HWC2hECGxLyeOawQtpfEohuXoGw1iavnNjFPYBSYhWTULCSjZiEZBWFrSZw 92swIE986/QwrhG0q0Tr9FFSNosTmA7uB4hxgNRc/R0KERSVW3JgD1aonMevXHfYFjFyrGDWK U4vKUot0jQz1kooy0zNKchMzc3QNDcz0clOLixPTU3MSk4r1kvNzNzECo4gBCHYw/lkWcIhRk oNJSZRXtmBOhBBfUn5KZUZicUZ8UWlOavEhRhkODiUJXge+uRFCgkWp6akVaZk5wHiGSUtw8C iJ8PKCpHmLCxJzizPTIVKnGHU5Tt04/ZJJiCUvPy9VSpyXFaRIAKQoozQPbgQstVxilJUS5mU EOkqIpyC1KDezBFX+FaM4B6OSMK8JyBSezLwSuE2vgI5gAjri+ulZIEeUJCKkpBoYK2flHE88 OfHke9WeG9VKIpcifRyuBd4NEPj9KzsvXk/b/sQF1wd3b3zYHhXp5To77ueMD6lry2V/8sW2+ EezL59TMI+3s+dazIujitX6z9LjFi7y+/MpaPGCRo+6vQ4/FkQuOfHrgMOc8ANXs3TOfTmTlF y3OXDvnJCreolbJAXrOFb9vHv5jBJLcUaioRZzUXEiAFIauNwoAwAA X-Env-Sender: sstabellini@kernel.org X-Msg-Ref: server-13.tower-27.messagelabs.com!1486688082!76839559!1 X-Originating-IP: [198.145.29.136] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 51967 invoked from network); 10 Feb 2017 00:54:43 -0000 Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.29.136) by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 10 Feb 2017 00:54:43 -0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0D1D7201BB; Fri, 10 Feb 2017 00:54:40 +0000 (UTC) Received: from [10.1.10.56] (96-82-76-110-static.hfc.comcastbusiness.net [96.82.76.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 740502011E; Fri, 10 Feb 2017 00:54:38 +0000 (UTC) Date: Thu, 9 Feb 2017 16:54:37 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: xen-devel@lists.xen.org Message-ID: User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-ID: X-Virus-Scanned: ClamAV using ClamSMTP Cc: george.dunlap@eu.citrix.com, edgar.iglesias@xilinx.com, dario.faggioli@citrix.com, sstabellini@kernel.org, julien.grall@arm.com Subject: [Xen-devel] Xen on ARM IRQ latency and scheduler overhead X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hi all, I have run some IRQ latency measurements on Xen on ARM on a Xilinx ZynqMP board (four Cortex A53 cores, GICv2). Dom0 has 1 vcpu pinned to cpu0, DomU has 1 vcpu pinned to cpu2. Dom0 is Ubuntu. DomU is an ad-hoc baremetal app to measure interrupt latency: https://github.com/edgarigl/tbm I modified the app to use the phys_timer instead of the virt_timer. You can build it with: make CFG=configs/xen-guest-irq-latency.cfg I modified Xen to export the phys_timer to guests, see the very hacky patch attached. This way, the phys_timer interrupt should behave like any conventional device interrupts assigned to a guest. These are the results, in nanosec: AVG MIN MAX WARM MAX NODEBUG no WFI 1890 1800 3170 2070 NODEBUG WFI 4850 4810 7030 4980 NODEBUG no WFI credit2 2217 2090 3420 2650 NODEBUG WFI credit2 8080 7890 10320 8300 DEBUG no WFI 2252 2080 3320 2650 DEBUG WFI 6500 6140 8520 8130 DEBUG WFI, credit2 8050 7870 10680 8450 DEBUG means Xen DEBUG build. WARM MAX is the maximum latency, taking out the first few interrupts to warm the caches. WFI is the ARM and ARM64 sleeping instruction, trapped and emulated by Xen by calling vcpu_block. As you can see, depending on whether the guest issues a WFI or not while waiting for interrupts, the results change significantly. Interestingly, credit2 does worse than credit1 in this area. Trying to figure out where those 3000-4000ns of difference between the WFI and non-WFI cases come from, I wrote a patch to zero the latency introduced by xen/arch/arm/domain.c:schedule_tail. That saves about 1000ns. There are no other arch specific context switch functions worth optimizing. We are down to 2000-3000ns. Then, I started investigating the scheduler. I measured how long it takes to run "vcpu_unblock": 1050ns, which is significant. I don't know what is causing the remaining 1000-2000ns, but I bet on another scheduler function. Do you have any suggestions on which one? Assuming that the problem is indeed the scheduler, one workaround that we could introduce today would be to avoid calling vcpu_unblock on guest WFI and call vcpu_yield instead. This change makes things significantly better: AVG MIN MAX WARM MAX DEBUG WFI (yield, no block) 2900 2190 5130 5130 DEBUG WFI (yield, no block) credit2 3514 2280 6180 5430 Is that a reasonable change to make? Would it cause significantly more power consumption in Xen (because xen/arch/arm/domain.c:idle_loop might not be called anymore)? If we wanted to zero the difference between the WFI and non-WFI cases, would we need a new scheduler? A simple "noop scheduler" that statically assigns vcpus to pcpus, one by one, until they run out, then return error? Or do we need more extensive modifications to xen/common/schedule.c? Any other ideas? Thanks, Stefano diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 7e43691..f5ff69b 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -663,6 +663,7 @@ void arch_domain_destroy(struct domain *d) /* IOMMU page table is shared with P2M, always call * iommu_domain_destroy() before p2m_teardown(). */ + WRITE_SYSREG32(0, CNTP_CTL_EL0); iommu_domain_destroy(d); p2m_teardown(d); domain_vgic_free(d); diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index a5348f2..5c8b621 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -47,7 +47,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask); static void gic_update_one_lr(struct vcpu *v, int i); -static const struct gic_hw_operations *gic_hw_ops; +const struct gic_hw_operations *gic_hw_ops; void register_gic_ops(const struct gic_hw_operations *ops) { diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index dd62ba6..9a4e50d 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -184,6 +184,7 @@ int request_irq(unsigned int irq, unsigned int irqflags, } /* Dispatch an interrupt */ +extern const struct gic_hw_operations *gic_hw_ops; void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq) { struct irq_desc *desc = irq_to_desc(irq); @@ -202,6 +203,12 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq) irq_enter(); spin_lock(&desc->lock); + + if (irq == 30) { + set_bit(_IRQ_GUEST, &desc->status); + desc->handler = gic_hw_ops->gic_guest_irq_type; + } + desc->handler->ack(desc); if ( !desc->action ) @@ -224,7 +231,23 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq) * The irq cannot be a PPI, we only support delivery of SPIs to * guests. */ - vgic_vcpu_inject_spi(info->d, info->virq); + if (irq != 30) + vgic_vcpu_inject_spi(info->d, info->virq); + else { + struct domain *d; + + for_each_domain ( d ) + { + struct pending_irq *p; + + if (d->domain_id == 0 || is_idle_domain(d)) + continue; + p = irq_to_pending(d->vcpu[0], 30); + p->desc = desc; + vgic_vcpu_inject_irq(d->vcpu[0], 30); + break; + } + } goto out_no_end; } diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c index 7dae28b..0249631 100644 --- a/xen/arch/arm/time.c +++ b/xen/arch/arm/time.c @@ -297,9 +300,9 @@ void init_timer_interrupt(void) /* Sensible defaults */ WRITE_SYSREG64(0, CNTVOFF_EL2); /* No VM-specific offset */ /* Do not let the VMs program the physical timer, only read the physical counter */ - WRITE_SYSREG32(CNTHCTL_EL2_EL1PCTEN, CNTHCTL_EL2); WRITE_SYSREG32(0, CNTP_CTL_EL0); /* Physical timer disabled */ WRITE_SYSREG32(0, CNTHP_CTL_EL2); /* Hypervisor's timer disabled */ + WRITE_SYSREG32(CNTHCTL_EL2_EL1PCTEN|CNTHCTL_EL2_EL1PCEN, CNTHCTL_EL2); isb(); request_irq(timer_irq[TIMER_HYP_PPI], 0, timer_interrupt,