Re: [Qemu-devel] [RFC v1 2/3] ramlist: apply fine grain lock for ram_list

[Paolo Bonzini <pbonzini@redhat.com>]

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