From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azjht-0004Mn-Sh for qemu-devel@nongnu.org; Mon, 09 May 2016 07:50:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azjho-0000cp-RW for qemu-devel@nongnu.org; Mon, 09 May 2016 07:50:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58425) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azjho-0000cY-LE for qemu-devel@nongnu.org; Mon, 09 May 2016 07:50:32 -0400 References: <1461827144-6937-1-git-send-email-peterx@redhat.com> <5721B980.4050903@web.de> <20160428091802.GH20143@pxdev.xzpeter.org> <20160429195214.GG15747@potion> <20160503032216.GA3296@pxdev.xzpeter.org> <57282B44.8080407@web.de> From: Paolo Bonzini Message-ID: <57307982.5070309@redhat.com> Date: Mon, 9 May 2016 13:50:26 +0200 MIME-Version: 1.0 In-Reply-To: <57282B44.8080407@web.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 00/18] IOMMU: Enable interrupt remapping for Intel IOMMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka , Peter Xu , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Cc: qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net, ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com, mst@redhat.com, alex.williamson@redhat.com, wexu@redhat.com On 03/05/2016 06:38, Jan Kiszka wrote: > Yes, this doesn't look good from the performance POV. Given that most > EOIs of the APICs will not trigger a message to an IOAPIC and userspace > exits are expensive, that should be measurable. > > But you should optimize route updating a bit: I noticed real delays > (almost a second) when reprogramming all IOAPIC pins during Jailhouse > handover. That's because of the heavyweight synchronize_srcu we have on > each route change. Even if that is an extreme case, you should try to > reduce route updates to only those that were actually affected by an > IRTE change. It's okay to make it synchronize_srcu_expedited. Unlike RCU, expediting SRCU grace periods doesn't have an impact on the whole system (the reason why KVM uses SRCU here is exactly to avoid synchronize_rcu_expedited). Of course, optimizing userspace cannot hurt either. Paolo