*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 <[email protected]> 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; >
