From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table Date: Thu, 28 Nov 2013 12:16:59 +0200 Message-ID: <5297181B.3090109@cloudius-systems.com> 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> <529712A1.8090207@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , "Zhanghaoyu (A)" , Gleb Natapov , Avi Kivity , "Huangweidong (C)" , KVM , "Michael S. Tsirkin" , "Jinxin (F)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong To: Paolo Bonzini Return-path: Received: from mail-bk0-f54.google.com ([209.85.214.54]:63252 "EHLO mail-bk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757926Ab3K1KRF (ORCPT ); Thu, 28 Nov 2013 05:17:05 -0500 Received: by mail-bk0-f54.google.com with SMTP id v16so3729582bkz.13 for ; Thu, 28 Nov 2013 02:17:03 -0800 (PST) In-Reply-To: <529712A1.8090207@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/28/2013 11:53 AM, Paolo Bonzini wrote: > 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. > I guess srcu would work. Do you know what's the typical write-side latency there? (in terms of what it waits for, not nanoseconds).