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(a)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@2133 MHz.
Michal