From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlzTM-0003D4-2l for qemu-devel@nongnu.org; Thu, 28 Nov 2013 06:09:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlzTE-0001u5-Pr for qemu-devel@nongnu.org; Thu, 28 Nov 2013 06:09:28 -0500 Received: from mail-wg0-f54.google.com ([74.125.82.54]:39438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlzTE-0001tt-KN for qemu-devel@nongnu.org; Thu, 28 Nov 2013 06:09:20 -0500 Received: by mail-wg0-f54.google.com with SMTP id n12so6975494wgh.33 for ; Thu, 28 Nov 2013 03:09:19 -0800 (PST) Date: Thu, 28 Nov 2013 13:09:15 +0200 From: Gleb Natapov Message-ID: <20131128110915.GD5822@minantech.com> References: <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> <5297181B.3090109@cloudius-systems.com> <52971D86.60601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52971D86.60601@redhat.com> 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: Paolo Bonzini Cc: Avi Kivity , "Huangweidong (C)" , Gleb Natapov , KVM , "Michael S. Tsirkin" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong , Avi Kivity , "Jinxin (F)" On Thu, Nov 28, 2013 at 11:40:06AM +0100, Paolo Bonzini wrote: > Il 28/11/2013 11:16, Avi Kivity ha scritto: > >> 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). > > If there's no concurrent reader, it's zero if I read the code right. > Otherwise it depends: > > - if there are many callbacks, only 10 of them are processed per > millisecond. But unless there are concurrent synchronize_srcu calls > there should not be any callback at all. If all VCPUs were to furiously > change the MSIs, the latency could go up to #vcpu/10 milliseconds. > > - if there are no callbacks, but there are readers, synchronize_srcu > busy-loops for some time checking if the readers complete. After a > while (20 us for synchronize_srcu, 120 us for > synchronize_srcu_expedited) it gives up and starts using a workqueue to > poll every millisecond. This should never happen unless > Unless what ? :) Unless reader is scheduled out? > So, given the very restricted usage this SRCU would have, we probably > can expect synchronize_srcu_expedited to finish its job in the > busy-looping phase, and 120 us should be the expected maximum > latency---more likely to be an order of magnitude smaller, and in very > rare cases higher. > > Paolo -- Gleb.