From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60990) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXphF-0003jI-ER for qemu-devel@nongnu.org; Mon, 12 Nov 2012 03:48:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXphC-0003k6-BG for qemu-devel@nongnu.org; Mon, 12 Nov 2012 03:48:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXphC-0003k1-3i for qemu-devel@nongnu.org; Mon, 12 Nov 2012 03:48:42 -0500 Message-ID: <50A0B7E0.1050101@redhat.com> Date: Mon, 12 Nov 2012 09:48:32 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1352430870-10129-1-git-send-email-qemulist@gmail.com> <1352430870-10129-3-git-send-email-qemulist@gmail.com> <509DB3EE.4060409@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1 2/3] ramlist: apply fine grain lock for ram_list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: Vasilis Liaskovitis , Stefan Hajnoczi , qemu-devel@nongnu.org, Anthony Liguori , Avi Kivity Il 12/11/2012 07:22, liu ping fan ha scritto: > On Sat, Nov 10, 2012 at 9:54 AM, Paolo Bonzini wrote: >> Il 09/11/2012 04:14, Liu Ping Fan ha scritto: >>> From: Liu Ping Fan >>> >>> Signed-off-by: Liu Ping Fan >>> --- >>> cpu-all.h | 1 + >>> exec.c | 46 +++++++++++++++++++++++++++++++++++++++------- >>> 2 files changed, 40 insertions(+), 7 deletions(-) >> >> The problem here is that the ram_list is a pretty critical bit for TCG. >> > This patch does not touch the MRU, so you mean the expense of lock? Yes. One alternative is to remove the MRU, but add a 1-item cache to speed up the common case. Then the case where you use the cache can be placed (later) in an RCU critical section. >> The migration thread series has patches that split the list in two: a >> MRU-accessed list that uses the BQL, and another that uses a separate lock. > > I read the thread, but I think we can not protect RAMBlock w/o a > unified lock. When ram device's refcnt->0, and call > qemu_ram_free_from_ptr(), it can be with/without QBL. Note that you would also split between unmap (which does QLIST_REMOVE) and free (which actually frees the block). qemu_ram_free_from_ptr() would really become qemu_ram_unmap_from_ptr(), and could do part of the work asynchronously---which makes it free to take and release locks as needed. I don't think it is problematic to delay the freeing of the blocks_mru item which requires BQL. Paolo