From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzNx8-0000ac-Bb for qemu-devel@nongnu.org; Thu, 09 Aug 2012 04:18:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzNx7-0006V0-39 for qemu-devel@nongnu.org; Thu, 09 Aug 2012 04:18:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzNx6-0006Up-Pv for qemu-devel@nongnu.org; Thu, 09 Aug 2012 04:18:45 -0400 Message-ID: <5023725A.2030306@redhat.com> Date: Thu, 09 Aug 2012 11:18:34 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-4-git-send-email-qemulist@gmail.com> <50222BC7.4060809@redhat.com> <50222C3B.1010302@redhat.com> <50222E2D.7050300@redhat.com> <50236B84.2020606@redhat.com> In-Reply-To: <50236B84.2020606@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 03/15] qom: introduce reclaimer to release obj List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kvm@vger.kernel.org, Jan Kiszka , Marcelo Tosatti , liu ping fan , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Stefan Hajnoczi , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 08/09/2012 10:49 AM, Paolo Bonzini wrote: > Il 09/08/2012 09:33, liu ping fan ha scritto: >> Yes, it is to defer destructors. >> See 0009-memory-prepare-flatview-and-radix-tree-for-rcu-style.patch >> When MemoryRegion is _del_subregion from mem in updater, it may be >> still in use by reader -- radix or flatview, so defer its destructors >> to the reclaimer --phys_map_release(PhysMap *map) > > How are you sure that the reader is already out of its critical section > by the time the reclaimer runs? > >> If we have rcu, it could be elegant to do this. > > Yeah, I think inventing primitives is dangerous and difficult to review; > and it may be difficult to replace it with proper call_rcu. > > You should probably make a proof-of-concept using liburcu. Then we can > decide how to implement RCU in a way that is portable enough for QEMU's > needs. IMO we should start with a simple mutex (which will cover only the lookup and map rebuild). This should reduce the contention to basically nothing (still leaving a cache line bounce). If a profile shows the cache line bounce hurting us, or perhaps contention in ultralarge guests, then we should switch to rcu. -- error compiling committee.c: too many arguments to function