On Mon, Nov 12, 2012 at 4:48 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > 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. > Right. Then just one thing left, the big lock may be called recursively. Do we have some elegant method to handle it?
Regards, Pingfan > Paolo
