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;
