Re: [Qemu-devel] [RFC] support memory reserved feature and optimize mlock guest memory propose

[Paolo Bonzini]

Il 06/03/2014 09:06, Zhanghailiang ha scritto:
> 
>> Il 05/03/2014 09:01, Zhanghailiang ha scritto:
>>> Hi all：
>>>
>>> Currently, we use cgroup(memory) to support memory QoS on KVM
>>> platform, and use "mlock" on qemu to support "memory reserved".
>>>
>>> The "mlock" seems to be not appropriate.
>>>
>>> Now qemu "mlock" memory in the main thread, which would lock iothread
>>> (qemu_mutex_lock_iothread), if the memory size is large, that will
>>> consume lots of time.
>>>
>>> It means whenever we want to set a new 'mlock', the VM would be
>>> blocked for a while.
>>
>> I'm not sure I understand how the mlock-ed memory is used.  Are you using a
>> custom malloc, for example with g_mem_set_vtable?
>>
>> Paolo
> 
> Hi Paolo：
> 
> Thanks for your reply.
> As you know qemu has an option "-mlock", I think it has some problems.
> If we set "-realtime mlock=on", then qemu will mlockall vm's memory, It is a 
> very time consuming action, and it will block the libvirt api until it 
> finished.
> so I think it is better to do 'mlock' asynchronously, the flow chart can be 
> described like below.

Is an asynchronous mlock valid for all workloads?  Until the mlock
finishes, there is no guarantee that the guest will have
"real-time--friendly" response to memory allocation.

> Is it ok? 
> Flow chart:
>            main funciton           qmp command "set_ram_minguarantee"
>                  |                           |
>                  |                           |
>         create "mlock" thread           change value of lock_ram_size
>                  |                           |
>                  |                           |
>     |------>thread wait<-------------wake up "mlock" thread
>     |            |
>     |            |
>     |            |
>     |-------mlock(lock_ram_zie)

Also, I'm not sure what the arguments to mlock are.  How do you find the
address range to pass to mlock?

Paolo