Red Hat Bugzilla – Bug 582282
VM backed by hugepages does not preallocate its memory
Last modified: 2013-01-09 17:27:10 EST
Created attachment 406536 [details]
Description of problem:
I've create a VM backed by hugepages, and since the -mem-prealloc parameter is passed, I would expect that all eight GB of memory allocated to the machine would get allocated right when the machine is started, but judging from /proc/meminfo, that doesn't seem to happen:
[root@gman ~]# grep HugePages /proc/meminfo
The full command-line is:
/usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 8000 -mem-prealloc -mem-path /mnt/hugepages/libvirt/qemu -smp 1 -name test -uuid c1c7a249-99fb-966a-947d-32632c11c3a1 -no-kvm-pit-reinjection -monitor pty -pidfile /var/run/libvirt/qemu//test.pid -boot d -drive file=/var/lib/libvirt/images/test.img,if=ide,index=0,cache=none -drive file=/var/lib/libvirt/images/RHEL4.8-x86_64-AS-disc1.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:66:61:24,vlan=0 -net tap,fd=15,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k fi
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. virsh create test.xml (attached)
Most of my HugePages still free
8 GB of my hugepages not free
On F13 and RHEL6 beta the -mem-prealloc seems to work and I see HugePages_Rsvd correctly showing the reserved amount of reserver memory, but I don't see this with RHEL5.5
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of
Red Hat Enterprise Linux. The error has been fixed and this
request has been re-proposed for the current release.
# rpm -q kvm
# uname -r
1.echo 3000 >/proc/sys/vm/nr_hugepages
2.mount -t hugetlbfs none /mnt/
3.start VM with -mem-prealloc
eg:/usr/libexec/qemu-kvm -M rhel5.6.0 -m 5G -smp 2 -name win2k3_64 -uuid 12bb419b-8730-cbbd-b0d9-168fa4225b6d -monitor stdio -boot dc -drive file=/home/fedora.img,if=ide,boot=on,format=raw,cache=none -net nic,macaddr=54:52:00:0e:bf:a1,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -serial pty -parallel none -usb -vnc :1 -k en-gb -vga cirrus -balloon virtio -mem-prealloc -mem-path /mnt
4.# grep HugePage /proc/meminfo
should 5GB of hugepage mem be used
The MAP_POPULATE implementation is quite different from RHEL5 to RHEL6 where it works safe, a backport isn't a matter of a few liner change, it could be a few liner changes but it would be different and it would carry a risk to userland using MAP_POPULATE that would run some new code. Backporting it for this feature that depends on hugetlbfs doesn't seem fundamental and it looks higher risk than whatever benefit it could provide and I'm generally conservative in the changes done to older kernels. I don't think this MAP_POPULATE qemu feature is critical enough to take any risk in this area. If the patch was already tested and could be backported simply (and didn't require new developments) it'd be different.
For THP and working MAP_POPULATE using RHEL6 sounds better choice than to take risks in RHEL5.