From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 06/15] memory: use refcnt to manage MemoryRegion Date: Thu, 09 Aug 2012 11:38:55 +0300 Message-ID: <5023771F.5030007@redhat.com> References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-7-git-send-email-qemulist@gmail.com> <50222F54.4080108@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Anthony Liguori , Jan Kiszka , Marcelo Tosatti , Stefan Hajnoczi , Paolo Bonzini , Blue Swirl , =?ISO-8859-1?Q?Andreas_F=E4rber?= To: liu ping fan Return-path: Received: from mx1.redhat.com ([209.132.183.28]:36718 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756163Ab2HIIjH (ORCPT ); Thu, 9 Aug 2012 04:39:07 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 08/09/2012 10:27 AM, liu ping fan wrote: > On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity wrote: >> On 08/08/2012 09:25 AM, Liu Ping Fan wrote: >>> From: Liu Ping Fan >>> >>> Using refcnt for mr, so we can separate mr's life cycle management >>> from refered object. >>> When mr->ref 0->1, inc the refered object. >>> When mr->ref 1->0, dec the refered object. >>> >>> The refered object can be DeviceStae, another mr, or other opaque. >> >> Please explain the motivation more fully. >> > Actually, the aim is to mange the reference of an object, used by mem view. > DeviceState can be referred by different system, when it comes to the > view of subsystem, we hold dev's ref. And any indirect reference will > just mr->ref++, not dev's. > This can help us avoid the down-walk through the referred chain, like > alias----> mr ---> DeviceState. That is a lot of complexity, for no gain. Manipulating memory regions is a slow path, and can be done under the bit qemu lock without any complications. > > In the previous discussion, you have suggest add dev->ref++ in > core_region_add. But I think, if we can move it to higher layer -- > memory_region_{add,del}_subregion, so we can avoid to duplicate do > this in other xx_region_add. Why would other memory listeners be impacted? They all operate under the big qemu lock. If they start using devices outside the lock, then they need to take a reference. > As a payment for this, we need to handle alias which can be avoid at > core_region_add(). And mr's ref can help to avoid > the down-walk. The payment is two systems of reference counts. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzOGm-00054E-Jo for qemu-devel@nongnu.org; Thu, 09 Aug 2012 04:39:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SzOGl-0004AK-Eh for qemu-devel@nongnu.org; Thu, 09 Aug 2012 04:39:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12533) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SzOGl-0004AC-4u for qemu-devel@nongnu.org; Thu, 09 Aug 2012 04:39:03 -0400 Message-ID: <5023771F.5030007@redhat.com> Date: Thu, 09 Aug 2012 11:38:55 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1344407156-25562-1-git-send-email-qemulist@gmail.com> <1344407156-25562-7-git-send-email-qemulist@gmail.com> <50222F54.4080108@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 06/15] memory: use refcnt to manage MemoryRegion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: kvm@vger.kernel.org, Jan Kiszka , Marcelo Tosatti , qemu-devel@nongnu.org, Blue Swirl , Anthony Liguori , Stefan Hajnoczi , Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= On 08/09/2012 10:27 AM, liu ping fan wrote: > On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity wrote: >> On 08/08/2012 09:25 AM, Liu Ping Fan wrote: >>> From: Liu Ping Fan >>> >>> Using refcnt for mr, so we can separate mr's life cycle management >>> from refered object. >>> When mr->ref 0->1, inc the refered object. >>> When mr->ref 1->0, dec the refered object. >>> >>> The refered object can be DeviceStae, another mr, or other opaque. >> >> Please explain the motivation more fully. >> > Actually, the aim is to mange the reference of an object, used by mem view. > DeviceState can be referred by different system, when it comes to the > view of subsystem, we hold dev's ref. And any indirect reference will > just mr->ref++, not dev's. > This can help us avoid the down-walk through the referred chain, like > alias----> mr ---> DeviceState. That is a lot of complexity, for no gain. Manipulating memory regions is a slow path, and can be done under the bit qemu lock without any complications. > > In the previous discussion, you have suggest add dev->ref++ in > core_region_add. But I think, if we can move it to higher layer -- > memory_region_{add,del}_subregion, so we can avoid to duplicate do > this in other xx_region_add. Why would other memory listeners be impacted? They all operate under the big qemu lock. If they start using devices outside the lock, then they need to take a reference. > As a payment for this, we need to handle alias which can be avoid at > core_region_add(). And mr's ref can help to avoid > the down-walk. The payment is two systems of reference counts. -- error compiling committee.c: too many arguments to function