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@xxxxxxxxxx> >>>> --- >>>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
