qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] colo-compare: reconstruct the mutex lock us


From: Hailiang Zhang
Subject: Re: [Qemu-devel] [PATCH 1/3] colo-compare: reconstruct the mutex lock usage
Date: Tue, 14 Feb 2017 15:33:41 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 2017/2/14 12:08, Jason Wang wrote:


On 2017年02月14日 10:32, Hailiang Zhang wrote:



Hi Jason,

I think the better way is notify the comparing thread and let it do the
releasing. You probably need similar mechanism to notify from comparing
thread to checkpoint thread.


It seems that there is no available APIs in glib to notify a thread which
are run coroutine to do something (idle source ?). What about using
anonymous pipe
as the GPollFD to communicate between colo comparing thread and colo
thread ?

Any ideas ?

Hailiang

Haven't thought this deeply. But I think you can try event notifier
first which was designed for such kind of notification.


Hmm, It is quite same with what i said above except it uses the
return value of eventfd as the GPollFD.
The things here are more complex especially if there are more than
one vNIC, which each is corresponding to one compare thread.

How about using g_source_attach(), g_source_attach(), g_source_remove(),
g_source_set_callback() and g_source_set_priority() to control the process
of releasing packets dynamically ? Which we call g_source_attach()
to add the coroutine of releasing packets when do checkpoint, and remove
it once finishing the checkpoint process.

About colo comparing thread notifies colo thread, i think we can use
qemu_cond_wait(),qemu_cond_broadcast(), just like what we do in
pause_all_vcpus().

Thanks.
Hailiang

Thanks

.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]