[libvirt] [PATCH 2/2] qemu: Adaptive timeout for connecting to monitor

[Michal Privoznik]

On 03/15/2017 03:28 PM, Jim Fehlig wrote:
> Michal Privoznik wrote:
>> On 03/15/2017 02:16 AM, Jim Fehlig wrote:
>>> On 03/13/2017 06:29 AM, Michal Privoznik wrote:
>>>> There were couple of reports on the list (e.g. [1]) that guests
>>>> with huge amounts of RAM are unable to start because libvirt
>>>> kills qemu in the initialization phase. The problem is that if
>>>> guest is configured to use hugepages kernel has to zero them all
>>>> out before handing over to qemu process. For instance, 402GiB
>>>> worth of 1GiB pages took around 105 seconds (~3.8GiB/s). Since we
>>>> do not want to make the timeout for connecting to monitor
>>>> configurable [2], we have to teach libvirt to count with this
>>>> fact. This commit implements "1s per each 1GiB of RAM" approach
>>>> as suggested here [3].
>>> FYI, on another machine I observed ~1.5 seconds for each 5G of memory.
>>>
>>>> 1: https://www.redhat.com/archives/libvir-list/2017-March/msg00373.html
>>>> 3: https://www.redhat.com/archives/libvir-list/2017-March/msg00405.html
>>>>
>>>> 2: The reason is that ideally someday it will be Libvirt who
>>>> creates the monitor socket and qemu will just use it.
>>> This point isn't clear to me wrt the changes done by the commit.
>>
>> Okay, I can remove it.
>>
>>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>>> ---
>>>>  src/qemu/qemu_capabilities.c |  2 +-
>>>>  src/qemu/qemu_monitor.c      | 36 +++++++++++++++++++++++++++++++-----
>>>>  src/qemu/qemu_monitor.h      |  1 +
>>>>  src/qemu/qemu_process.c      |  8 ++++++++
>>>>  tests/qemumonitortestutils.c |  1 +
>>>>  5 files changed, 42 insertions(+), 6 deletions(-)
>>>>
>>
>>
>>> Looks good. You can decide about the nits. ACK in principle, but I'm not
>>> able to test this ATM. The host I was using is now running a VM that
>>> uses most of its memory. Matt might be running a test in that VM so I
>>> don't want to kill it :-). I can test the patches tomorrow and report
>>> back if you want to wait a bit before pushing.
>>
>> Sure. I will wait for your report and thus full ACK.
> 
> Test results were positive. ACK series.

Thank you. I've pushed all the patches. If we ever find that our
guessing algorithm doesn't work we can revisit it.

BTW: I've run couple of tests myself too and am quite surprised to learn
that it takes ages to zero out memory. On my system it's about
~3.6GiB/s. And this is DDR4 at 2133 MHz.

Michal