Created attachment 406536 [details] test machine 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 HugePages_Total: 5000 HugePages_Free: 4793 HugePages_Rsvd: 0 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): kvm-83-164.el5 How reproducible: Every time Steps to Reproduce: 1. virsh create test.xml (attached) 2. 3. Actual results: Most of my HugePages still free Expected results: 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.
Reproduced on # rpm -q kvm kvm-83-224.el5 # uname -r 2.6.18-237.el5 steps: 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 HugePages_Total: 3000 HugePages_Free: 2681 HugePages_Rsvd: 0 Excepted Results: 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.