Re: [PATCH] kvm tools: Use mmap for working with disk image V2

[Gleb Natapov <gleb@redhat.com>]

On Sun, Apr 10, 2011 at 11:15:29AM +0300, Avi Kivity wrote:
> On 04/09/2011 03:20 PM, Alexander Graf wrote:
> >On 09.04.2011, at 14:14, Sasha Levin wrote:
> >
> >>  Attempt to use mmap first for working with a disk image, if the attempt is failed (for example, large image on a 32bit system) fallback to using read/write.
> >
> >That reminds me of an idea I had quite a while back.
> >
> >What if we mmap'ed a raw disk image directly into the guest's address space? This could for example be done through a virtio feature addition, keeping the disk accessible through normal virtio plus the mmap'ed part. At least in writeback mode, this should perform pretty well, as we'd save all the userspace exits. It'd basically be almost like vhost-blk :).
> >
> >Have you thought about trying out to implement such a feature?
> 
> A creative idea, but I don't think it will work.  On EPT hosts we
> don't have accessed/dirty bits so you have to incur at least write
> faults to track dirty data and perhaps read faults to gather recency
> information.  On non-EPT you have to scan page tables to find out
> what you have to write out, and flush TLBs.  Cache misses, which
> you'd expect there to be quite a few, would stall the vcpu (unless
> you use asynchronous page faults) and contribute less information to
> the host than virtio-blk (location of access but not size).  Write
> misses are converted to read-modify-write operations.
> 
Guest kernel can keep track of all modified sectors and pass it to
hypervisor with sync command.

> Even in userspace I think mmap() is usually not a performance win.
> It's advantages are that it's simple to use and has low set-up time,
> which is useful for short lived processes, especially with read-only
> backing files.  For virtual machines it's much worse.
> 
> -- 
> error compiling committee.c: too many arguments to function
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.