Re: [Qemu-devel] [RFC PATCH v4 00/28] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service

[Wen Congyang <wency@cn.fujitsu.com>]

On 04/22/2015 07:18 PM, Dr. David Alan Gilbert wrote:
> * zhanghailiang (zhang.zhanghailiang@huawei.com) 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
> 
>>