<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 25, 2017 at 4:12 PM, Jiri Denemark <span dir="ltr"><<a href="mailto:jdenemar@redhat.com" target="_blank">jdenemar@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Oct 24, 2017 at 10:34:53 -0700, Prerna Saxena wrote:<br>
><br>
> As noted in<br>
> <a href="https://www.redhat.com/archives/libvir-list/2017-May/msg00016.html" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>archives/libvir-list/2017-May/<wbr>msg00016.html</a><br>
> libvirt-QEMU driver handles all async events from the main loop.<br>
> Each event handling needs the per-VM lock to make forward progress. In<br>
> the case where an async event is received for the same VM which has an<br>
> RPC running, the main loop is held up contending for the same lock.<br>
><br>
> This impacts scalability, and should be addressed on priority.<br>
><br>
> Note that libvirt does have a 2-step deferred handling for a few event<br>
> categories, but (1) That is insufficient since blockign happens before<br>
> the handler could disambiguate which one needs to be posted to this<br>
> other queue.<br>
> (2) There needs to be homogeniety.<br>
><br>
> The current series builds a framework for recording and handling VM<br>
> events.<br>
> It initializes per-VM event queue, and a global event queue pointing to<br>
> events from all the VMs. Event handling is staggered in 2 stages:<br>
> - When an event is received, it is enqueued in the per-VM queue as well<br>
>   as the global queues.<br>
> - The global queue is built into the QEMU Driver as a threadpool<br>
>   (currently with a single thread).<br>
> - Enqueuing of a new event triggers the global event worker thread, which<br>
>   then attempts to take a lock for this event's VM.<br>
>     - If the lock is available, the event worker runs the function handling<br>
>       this event type. Once done, it dequeues this event from the global<br>
>       as well as per-VM queues.<br>
>     - If the lock is unavailable(ie taken by RPC thread), the event worker<br>
>       thread leaves this as-is and picks up the next event.<br>
<br>
</div></div>If I get it right, the event is either processed immediately when its VM<br>
object is unlocked or it has to wait until the current job running on<br>
the VM object finishes even though the lock may be released before that.<br>
Correct? If so, this needs to be addressed.<br></blockquote><div><br></div><div>In most cases, the lock is released just before we end the API. However, it is a small change that can be made. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> - Once the RPC thread completes, it looks for events pertaining to the<br>
>   VM in the per-VM event queue. It then processes the events serially<br>
>   (holding the VM lock) until there are no more events remaining for<br>
>   this VM. At this point, the per-VM lock is relinquished.<br>
><br>
> Patch Series status:<br>
> Strictly RFC only. No compilation issues. I have not had a chance to<br>
> (stress) test it after rebase to latest master.<br>
> Note that documentation and test coverage is TBD, since a few open<br>
> points remain.<br>
><br>
> Known issues/ caveats:<br>
> - RPC handling time will become non-deterministic.<br>
> - An event will only be "notified" to a client once the RPC for same VM completes.<br>
> - Needs careful consideration in all cases where a QMP event is used to<br>
>   "signal" an RPC thread, else will deadlock.<br>
<br>
</span>This last issue is actually a show stopper here. We need to make sure<br>
QMP events are processed while a job is still active on the same domain.<br>
Otherwise thinks kile block jobs and migration, which are long running<br>
jobs driven by events, will break.<br>
<br>
Jirka<br>
</blockquote></div>Completely agree, which is why I have explicitly mentioned this.</div><div class="gmail_extra">However, I do not completely follow why it needs to be this way. Can the block job APIs between QEMU <--> libvirt be fixed so that such behaviour is avoided ?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Prerna</div></div>