<div dir="ltr"><b>Hi Venkatesh,</b><div><br></div><div>Sorry for the incomplete mail. I wanted to say that the following project also shares the same motivation of bringing down the total no. of VM exits. </div><div><br></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">* When running DragonFly as a guest on KVM, we take a lot of VM exits,</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> particularly to our host/VMM's APIC device. We could implement a</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> kvmclock time source to avoid some timer exits and support for the</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> paravirtualized EOI (</span><a href="https://lwn.net/Articles/502176/" target="_blank" style="font-family:arial,sans-serif;font-size:13px">https://lwn.net/Articles/<u></u>502176/</a><span style="font-family:arial,sans-serif;font-size:13px">) in our platform</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> code to cut down on VM exits.</span><br style="font-family:arial,sans-serif;font-size:13px"></div><div><br></div><div>Although the work would be different than the previous, but the ultimate goal is the same. I was also wondering how it would be different for Xen as a host, because paravirtualization in Xen and KVM is a bit different [1]. Also, under the umbrella of "Performance Analysis and Improvements of DragonFly Guest by reducing the no. of exits", both of the projects can be implemented. Kindly let me know your view. Also, please point me to the code references/documentation for the same.</div>
<div><br></div><div><br></div><div>References :</div><div>[1] <a href="http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/">http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/</a><br>
</div><div><br></div><div><br></div><div class="gmail_extra"><div><b><div><b>---------------------------- <br></b></div>Thanks & Regards<br><font color="#888888">Mohit Dhingra <br>+919611190435</font></b></div>
<br><br><div class="gmail_quote">On 21 March 2013 12:58, Mohit Dhingra <span dir="ltr"><<a href="mailto:mohitdhingras@gmail.com" target="_blank">mohitdhingras@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><b>Hi Venkatesh,</b><div><br></div><div>Thanks for clarifications and support. I have been looking around for the problem of VM exits. I think the following project also shares the same motivation of bringing down the no. of VM exits </div>
<div><br><div class="gmail_extra"><div class="im"><br clear="all"><div><b><div><b>---------------------------- <br></b></div>Thanks & Regards<br><font color="#888888">Mohit Dhingra <br>+919611190435</font></b></div>
<br><br></div><div><div class="h5"><div class="gmail_quote">On 21 March 2013 03:00, Venkatesh Srinivas <span dir="ltr"><<a href="mailto:vsrinivas@ops101.org" target="_blank">vsrinivas@ops101.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Tue, Mar 05, 2013 at 03:15:12PM +0530, Mohit Dhingra wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
*Hi Venkatesh,*<div><br>
<br>
Thanks a lot for a nice explanatory mail!<br>
<br>
I found the second project quite interesting, just to repeat --<br>
** virtio-blk currently 'kicks' the host VMM directly from its<br>
strategy() routine; it may make sense to defer this to a taskqueue. This<br>
is a tiny change, but understanding the performance implications may<br>
take a bit longer.<br>
<br>
As per my understanding, the notification to host through kick() involves<br>
the exit of the guest (as per attached paper). Hence, the aim for this<br>
project would also be to minimize the exits, or rather instantaneous exits.<br>
Deferring it to the task queue should definitely help. Other things that<br>
can be done in this project is batching of the buffers before kick() and<br>
dynamically deciding how many buffers can be batched together.<br>
<br>
Also, not all of the times deferring the 'kick' to taskqueue might not be a<br>
good idea. Finding those scenarios would be interesting where it helps, and<br>
where it is merely an overhead.<br>
</div></blockquote>
<br>
Yep, your understanding is correct. <br>
QEMU and friends generally try to handle batches of requests per-VMexit, so sometimes (often) there are wins to deferred 'kicks'. <br><div>
On Mon, Mar 11, 2013 at 09:42:08PM +0530, Mohit Dhingra wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Venkatesh,<br>
Will you be able to mentor this project? I actually wanted to get<br>
some<br>
more info and hands on before applying for GSoC project. Please also<br>
check<br>
the previous mail and my proposal.<br>
</blockquote>
<br></div>
I'd be happy to mentor a project to work on performance of DFly under<br>
virtualization (KVM or w/e), but this alone would be too small for a<br>
full GSoC project, I think. Working on a few of the aspects I mentioned<br>
earlier (or anything you come up with! very strongly encouraged!) would<br>
be a better fit for a full project.<br>
Take care,<br>
-- vs;<br>
</blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div></div>