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 [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
