Il 12/11/2012 07:22, liu ping fan ha scritto: > On Sat, Nov 10, 2012 at 9:54 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 09/11/2012 04:14, Liu Ping Fan ha scritto: >>> From: Liu Ping Fan <pingf...@linux.vnet.ibm.com> >>> >>> Signed-off-by: Liu Ping Fan <pingf...@linux.vnet.ibm.com> >>> --- >>> 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
