From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlyIK-0005mH-Tm for qemu-devel@nongnu.org; Thu, 28 Nov 2013 04:54:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlyIE-00016k-VP for qemu-devel@nongnu.org; Thu, 28 Nov 2013 04:54:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlyIE-00016g-Lh for qemu-devel@nongnu.org; Thu, 28 Nov 2013 04:53:54 -0500 Message-ID: <529712A1.8090207@redhat.com> Date: Thu, 28 Nov 2013 10:53:37 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <52949847.6020908@redhat.com> <5294A68F.6060301@redhat.com> <5294B461.5000405@redhat.com> <5294B634.4050801@cloudius-systems.com> <20131126150357.GA20352@redhat.com> <5294BC3B.6070902@redhat.com> <5297050E.6000700@redhat.com> <20131128091903.GA4609@kernel.org> <5297118C.3050104@cloudius-systems.com> In-Reply-To: <5297118C.3050104@cloudius-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "Huangweidong (C)" , Gleb Natapov , KVM , "Michael S. Tsirkin" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong , Avi Kivity , Gleb Natapov , "Jinxin (F)" Il 28/11/2013 10:49, Avi Kivity ha scritto: > Linux is safe, it does interrupt migration from within the interrupt > handler. If you do that before the device-specific EOI, you won't get > another interrupt until programming the MSI is complete. > > Is virtio safe? IIRC it can post multiple interrupts without guest acks. > > Using call_rcu() is a better solution than srcu IMO. Less code changes, > consistently faster. call_rcu() has the problem of rate limiting, too. It wasn't such a great idea, I think. The QRCU I linked would work great latency-wise (it has roughly the same latency of an rwsem but readers are lock-free). However, the locked operations in the read path would hurt because of cache misses, so it's not good either. Paolo