[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: |
liu ping fan |
Subject: |
Re: [Qemu-devel] [RFC v1 2/3] ramlist: apply fine grain lock for ram_list |
Date: |
Tue, 13 Nov 2012 14:07:00 +0800 |
On Mon, Nov 12, 2012 at 4:48 PM, Paolo Bonzini <address@hidden> wrote:
> 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.
>
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
[Qemu-devel] [RFC v1 3/3] make address_space_map safe, Liu Ping Fan, 2012/11/08