On 24.03.15 10:46, Adrian Schröter wrote: > On Dienstag, 24. März 2015, 10:41:21 wrote Alexander Graf: >> >> On 24.03.15 10:35, Adrian Schröter wrote: >>> On Dienstag, 24. März 2015, 10:09:10 wrote Alexander Graf: >>>> >>>> On 24.03.15 09:59, Andreas Schwab wrote: >>>>> [ 0s] Using BUILD_ROOT=/var/cache/obs/worker/root_4/.mount >>>>> [ 0s] Using BUILD_ARCH=armv7l:armv6l:armv5tel >>>>> [ 0s] Doing kvm build in /var/cache/obs/worker/root_4/root >>>>> [ 0s] >>>>> [ 1s] >>>>> [ 1s] armbuild18 started "build exaile.spec" at Tue Mar 24 08:56:31 >>>>> UTC 2015. >>>>> [ 1s] >>>>> [ 1s] Building exaile for project 'openSUSE:Factory:ARM' repository >>>>> 'standard' arch 'armv7l' srcmd5 '8b532eeba6b98fb5fe5eccd4482f2568' >>>>> [ 1s] >>>>> [ 1s] processing recipe >>>>> /var/cache/obs/worker/root_4/.build-srcdir/exaile.spec ... >>>>> [ 1s] running changelog2spec --target rpm --file >>>>> /var/cache/obs/worker/root_4/.build-srcdir/exaile.spec >>>>> [ 1s] init_buildsystem --configdir /var/run/obs/worker/4/build/configs >>>>> --cachedir /var/cache/build --prepare --clean --rpmlist >>>>> /var/cache/obs/worker/root_4/.build.rpmlist >>>>> /var/cache/obs/worker/root_4/.build-srcdir/exaile.spec build >>>>> rpmlint-Factory ... >>>>> [ 2s] hostname: Name or service not known >>>>> [ 2s] unpacking preinstall image >>>>> openSUSE:Factory:ARM/standard/preinstallimage-base >>>>> [5bc6056231bc911005b9fc63638e5440] >>>>> [ 11s] ................. >>>>> [ 11s] >>>>> [ 11s] copying packages... >>>>> [ 15s] reordering...cycle: gio-branding-upstream -> libgio-2_0-0 >>>>> [ 15s] breaking dependency libgio-2_0-0 -> gio-branding-upstream >>>>> [ 15s] cycle: girepository-1_0 -> libgirepository-1_0-1 >>>>> [ 15s] breaking dependency libgirepository-1_0-1 -> girepository-1_0 >>>>> [ 15s] done >>>>> [ 16s] ### WATCHDOG MARKER START ### >>>>> [ 16s] booting kvm... >>>>> [ 16s] linux64 /usr/bin/qemu-system-arm -no-reboot -nographic -vga none >>>>> -net none -enable-kvm -M virt -cpu host -mem-prealloc -mem-path >>>>> /dev/hugepages -kernel /boot/zImage.guest -initrd /boot/initrd -append >>>>> root=/dev/disk/by-id/virtio-0 panic=1 quiet no-kvmclock nmi_watchdog=0 rw >>>>> rd.driver.pre=binfmt_misc elevator=noop console=ttyAMA0 >>>>> init=/.build/build -m 1020 -drive >>>>> file=/var/cache/obs/worker/root_4/root,if=none,id=disk,serial=0,cache=unsafe >>>>> -device virtio-blk-device,drive=disk -drive >>>>> file=/var/cache/obs/worker/root_4.swap,if=none,id=swap,serial=1,cache=unsafe >>>>> -device virtio-blk-device,drive=swap -smp 1 >>>>> [ 17s] Cannot set up guest memory 'mach-virt.ram': Cannot allocate >>>>> memory >>>>> [ 17s] ### WATCHDOG MARKER END ### >>>>> [ 17s] No buildstatus set, either the base system is broken >>>>> (kernel/initrd/udev/glibc/bash/perl) >>>>> [ 17s] or the build host has a kernel or hardware problem... >>>> >>>> While 3 VMs are happily running I see the following in /proc/meminfo on >>>> armbuild18: >>>> >>>> HugePages_Total: 2080 >>>> HugePages_Free: 2080 >>>> HugePages_Rsvd: 0 >>>> HugePages_Surp: 0 >>>> >>>> which means QEMU isn't using huge pages. Dirk, have you updated QEMU on >>>> the workers and maybe used a version with broken hugetlbfs support? >>> >>> the build script got updated these days ... >>> >>> However, I do not see a problem with it there, since it works on other >>> hosts and also the parameters of kvm start looks okay to me here >> >> The parameters look ok to me too, so I doubt that it's the build script. >> >> Basically what happens is that we reserve 4GB of RAM for VMs on boot to >> be used with hugetlbfs. The systems have 8GB RAM total. >> >> If we now start VMs with a broken QEMU that doesn't use hugetlbfs (like >> the one on armbuild18), it will just grab memory from the remaining >> non-reserved 4GB of system memory. That will work, but will eventually >> lead to swapping and potentially OOM situations, as well as degrade >> performance (huge pages give ~10-20% performance boost) and in certain >> situations mean that you can't run 4 VMs anymore, but only 3. > > Yes, I have commented out the hugtblfs config for now on armbuild18.
I don't think it's limited to armbuild18. And we really should use hugetlbfs ;). Let's just wait for Dirk to reply. I'm pretty sure he updated QEMU and didn't realize that hugetlbfs was unused. > Luckily these kind of errors are handled as brokenhost by OBS, so > it did not caused any build failures. Yup. Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
