On 06/19/2012 02:21 PM, Dor Laor wrote:
On 06/19/2012 05:51 AM, Asias He wrote:
On 06/18/2012 07:39 PM, Sasha Levin wrote:
On Mon, 2012-06-18 at 14:14 +0300, Dor Laor wrote:
On 06/18/2012 01:05 PM, Rusty Russell wrote:
On Mon, 18 Jun 2012 16:03:23 +0800, Asias He<asias@xxxxxxxxxx> wrote:
On 06/18/2012 03:46 PM, Rusty Russell wrote:
On Mon, 18 Jun 2012 14:53:10 +0800, Asias He<asias@xxxxxxxxxx>
wrote:
This patch introduces bio-based IO path for virtio-blk.
Why make it optional?
request-based IO path is useful for users who do not want to bypass
the
IO scheduler in guest kernel, e.g. users using spinning disk. For
users
using fast disk device, e.g. SSD device, they can use bio-based IO
path.
Users using a spinning disk still get IO scheduling in the host
though.
What benefit is there in doing it in the guest as well?
The io scheduler waits for requests to merge and thus batch IOs
together. It's not important w.r.t spinning disks since the host can do
it but it causes much less vmexits which is the key issue for VMs.
Is the amount of exits caused by virtio-blk significant at all with
EVENT_IDX?
Yes. EVENT_IDX saves the number of notify and interrupt. Let's take the
interrupt as an example, The guest fires 200K request to host, the
number of interrupt is about 6K thanks to EVENT_IDX. The ratio is 200K /
6K = 33. The ratio of merging is 40000K / 200K = 20.
In this case, why don't you always recommend bio over request based?
This case shows that IO scheduler's merging in guest saves a lot of
requests to host side. Why should I recommend bio over request based here?
--
Asias
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
