>>>>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. An additional copy will be avoided only by using vhost, so if you are using vhost you can call it zero copy realtively. -----Original Message----- From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] On Behalf Of Marcus White Sent: Tuesday, June 03, 2014 2:50 AM To: Zhang Haoyu Cc: kvm Subject: Re: Some more basic questions.. 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 ��.n��������+%������w��{.n�����o�^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
