[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v4 00/28] COarse-grain LOck-stepping(COLO) V
From: |
Wen Congyang |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 00/28] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service |
Date: |
Fri, 24 Apr 2015 15:25:17 +0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
On 04/22/2015 07:18 PM, Dr. David Alan Gilbert wrote:
> * zhanghailiang (address@hidden) wrote:
>> Hi,
>>
>> ping ...
>
> I will get to look at this again; but not until after next week.
>
>> The main blocked bugs for COLO have been solved,
>
> I've got the v3 set running, but the biggest problem I hit are problems
> with the packet comparison module; I've seen a panic which I think is
> in colo_send_checkpoint_req that I think is due to the use of
> GFP_KERNEL to allocate the netlink message and I think it can schedule
> there. I tried making that a GFP_ATOMIC but I'm hitting other
> problems with :
Thanks for your test.
I guest the backtrace should like:
1. colo_send_checkpoint_req()
2. colo_setup_checkpoint_by_id()
Because we hold rcu read lock, so we cannot use GFP_KERNEL to malloc memory.
>
> kcolo_thread, no conn, schedule out
Hmm, how to reproduce it? In my test, I only focus on block replication, and
I don't use the network.
>
> that I've not had time to look into yet.
>
> So I only get about a 50% success rate of starting COLO.
> I see there are stuff in the TODO of the colo-proxy that
> seem to say the netlink stuff should change, maybe you're already fixing
> that?
Do you mean you get about a 50% success rate if you use the network?
Thanks
Wen Congyang
>
>> we also have finished some new features and optimization on COLO. (If you
>> are interested in this,
>> we can send them to you in private ;))
>
>> For easy of review, it is better to keep it simple now, so we will not add
>> too much new codes into this frame
>> patch set before it been totally reviewed.
>
> I'd like to see those; but I don't want to take code privately.
> It's OK to post extra stuff as a separate set.
>
>> COLO is a totally new feature which is still in early stage, we hope to
>> speed up the development,
>> so your comments and feedback are warmly welcomed. :)
>
> Yes, it's getting there though; I don't think anyone else has
> got this close to getting a full FT set working with disk and networking.
>
> Dave
>
>>