Google Summer of Code

[Mohit Dhingra]

*Hi Venkatesh,*

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.

* When running DragonFly as a guest on KVM, we take a lot of VM exits,
  particularly to our host/VMM's APIC device. We could implement a
  kvmclock time source to avoid some timer exits and support for the
  paravirtualized EOI
(https://lwn.net/Articles/**502176/<https://lwn.net/Articles/502176/>)
in our platform
  code to cut down on VM exits.

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.


References :
[1]
http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/


*
----------------------------
Thanks & Regards
Mohit Dhingra
+919611190435*


On 21 March 2013 12:58, Mohit Dhingra <mohitdhingras at gmail.com> wrote:

> *Hi Venkatesh,*
>
> 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
>
>
> *
> ----------------------------
> Thanks & Regards
> Mohit Dhingra
> +919611190435*
>
>
> On 21 March 2013 03:00, Venkatesh Srinivas <vsrinivas at ops101.org> wrote:
>
>> On Tue, Mar 05, 2013 at 03:15:12PM +0530, Mohit Dhingra wrote:
>>
>>> *Hi Venkatesh,*
>>>
>>>
>>> Thanks a lot for a nice explanatory mail!
>>>
>>> I found the second project quite interesting, just to repeat  --
>>> ** virtio-blk currently 'kicks' the host VMM directly from its
>>>   strategy() routine; it may make sense to defer this to a taskqueue.
>>> This
>>>   is a tiny change, but understanding the performance implications may
>>>   take a bit longer.
>>>
>>> As per my understanding, the notification to host through kick() involves
>>> the exit of the guest (as per attached paper). Hence, the aim for this
>>> project would also be to minimize the exits, or rather instantaneous
>>> exits.
>>> Deferring it to the task queue should definitely help. Other things that
>>> can be done in this project is batching of the buffers before kick() and
>>> dynamically deciding how many buffers can be batched together.
>>>
>>> Also, not all of the times deferring the 'kick' to taskqueue might not
>>> be a
>>> good idea. Finding those scenarios would be interesting where it helps,
>>> and
>>> where it is merely an overhead.
>>>
>>
>> Yep, your understanding is correct.
>> QEMU and friends generally try to handle batches of requests per-VMexit,
>> so sometimes (often) there are wins to deferred 'kicks'.
>> On Mon, Mar 11, 2013 at 09:42:08PM +0530, Mohit Dhingra wrote:
>>
>>>   Hi Venkatesh,
>>>   Will you be able to mentor this project? I actually wanted to get
>>>   some
>>>   more info and hands on before applying for GSoC project. Please also
>>>   check
>>>   the previous mail and my proposal.
>>>
>>
>> I'd be happy to mentor a project to work on performance of DFly under
>> virtualization (KVM or w/e), but this alone would be too small for a
>> full GSoC project, I think. Working on a few of the aspects I mentioned
>> earlier (or anything you come up with! very strongly encouraged!) would
>> be a better fit for a full project.
>>  Take care,
>> -- vs;
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130321/802b38e0/attachment-0002.html>