A few additional questions:) 1. If IO to a block device goes through QEMU and not vhost, are there data copies between kernel and user mode if I do IO to a block device or is it zero copy? Kind of related to Question (2) also. 2. A related question to (1), is the QEMU process separate from the VM process or do they all run on the same process as different threads? I did read about IO threads and it seemed like they are all part of the same process, wanted to confirm. Thank you:) On Thu, May 29, 2014 at 11:48 PM, Zhang Haoyu <zhanghy@xxxxxxxxxxx> wrote: >>Thanks Zhang and Venkateshwara, some more follow up questions below:) >> >>1. Does -realtime mlock=on allocate all the memory upfront and keep it >>for the VM, or does it just make sure the memory that is allocated >>within the guest is not swapped out under host memory pressure? >> > “-realtime mlock=on” will mlockall(MCL_CURRENT | MCL_FUTURE) QEMU's ALL memory, > because VM's memory is part of QEMU's, so this option will keep VM's memory unswapped. > >>2. I notice on a 4G guest on an 8G host, guest allocates only about >>1G initially, and the rest later as I start applications. Is there a >>way for me to reserve ALL memory (4G in this case) upfront somehow >>without changes to guest and without allocating it? It will have to be >>something the host OS or some component within the host OS. Isnt there >>something to that effect? It seems odd that there isnt. >> > On linux, user-process's memory is allocating on demand, the physical memory does not allocate until the virtual memory is touched. > Because VM's memory is part of QEMU's, so ... > I guess the VM you said above is linux guest. Windows guest will memset its memory during booting period. > > You can use "-realtime mlock=on" to reserve VM's ALL memory upfront. > >> >>Thank you in advance. -- 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
