From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZzGO-0001Nc-81 for qemu-devel@nongnu.org; Wed, 08 May 2013 03:58:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZzGN-0004k6-7p for qemu-devel@nongnu.org; Wed, 08 May 2013 03:58:12 -0400 Received: from david.siemens.de ([192.35.17.14]:19714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZzGM-0004jq-Tq for qemu-devel@nongnu.org; Wed, 08 May 2013 03:58:11 -0400 Message-ID: <518A0587.9050409@siemens.com> Date: Wed, 08 May 2013 09:57:59 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1367936238-12196-1-git-send-email-pbonzini@redhat.com> <1367936238-12196-41-git-send-email-pbonzini@redhat.com> <5189415B.5070108@siemens.com> <51895995.20905@redhat.com> In-Reply-To: <51895995.20905@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 40/40] memory: add reference counting to FlatView List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "aik@ozlabs.ru" , "qemulist@gmail.com" , "qemu-devel@nongnu.org" , "stefanha@redhat.com" , "david@gibson.dropbear.id.au" On 2013-05-07 21:44, Paolo Bonzini wrote: > Il 07/05/2013 20:00, Jan Kiszka ha scritto: >> On 2013-05-07 16:17, Paolo Bonzini wrote: >>> With this change, a FlatView can be used even after a concurrent >>> update has replaced it. Because we do not have RCU, we use a >>> mutex to protect the small critical sections that read/write the >>> as->current_map pointer. Accesses to the FlatView can be done >>> outside the mutex. >>> >>> If a MemoryRegion will be used after the FlatView is unref-ed (or after >>> a MemoryListener callback is returned), a reference has to be added to >>> that MemoryRegion. For example, memory_region_find adds a reference to >>> the MemoryRegion that it returns. >> >> For my understanding: Every lookup, e.g. triggered by address_space_rw, >> will briefly reference the FlatView of that address space and drop that >> reference again after referencing the target memory region. >> >> Provided that is true: If we run that lookup on an address space that >> happens to be modified in parallel, the lookup may actually cause the >> final deref and, thus, release of the FlatView - even if the target >> memory region was totally unrelated to the ongoing change. That could >> make a hot-path pay the price of an action a slow path caused. Not >> really a beautiful concept. Even if the FlatView finalization is a >> simple free() (that is the minimum), we would pull the memory allocator >> into code paths that might try hard to keep a safe distance for the sake >> of predictability. > > All this is correct. But I hope to get RCU in 1.6, otherwise we can use > a bottom half. In any case, this is obviously no worse than current > code that requires the BQL (hence the lookup would serialize against the > free). Sure, not a regression. But I'd like to avoid that we are moving in the potentially wrong direction /wrt final goal. And I'm very interested in having increments that can be used in RT demonstration scenarios without having to hack too much on the code. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux