[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v1 2/3] ramlist: apply fine grain lock for ram_lis
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC v1 2/3] ramlist: apply fine grain lock for ram_list |
Date: |
Mon, 12 Nov 2012 09:48:32 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 |
Il 12/11/2012 07:22, liu ping fan ha scritto:
> On Sat, Nov 10, 2012 at 9:54 AM, Paolo Bonzini <address@hidden> wrote:
>> Il 09/11/2012 04:14, Liu Ping Fan ha scritto:
>>> From: Liu Ping Fan <address@hidden>
>>>
>>> Signed-off-by: Liu Ping Fan <address@hidden>
>>> ---
>>> 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
[Qemu-devel] [RFC v1 3/3] make address_space_map safe, Liu Ping Fan, 2012/11/08