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

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.

> > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > --- > 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.