Bug 582282 - VM backed by hugepages does not preallocate its memory
VM backed by hugepages does not preallocate its memory
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Andrea Arcangeli
Virtualization Bugs
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
Reported: 2010-04-14 10:44 EDT by David Juran
Modified: 2013-01-09 17:27 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-08-07 09:06:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test machine (1.39 KB, text/xml)
2010-04-14 10:44 EDT, David Juran
no flags Details

  None (edit)
Description David Juran 2010-04-14 10:44:11 EDT
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 -k fi

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. virsh create test.xml (attached)
Actual results:
Most of my HugePages still free

Expected results:
8 GB of my hugepages not free
Comment 1 Andrew Cathrow 2010-07-26 16:38:37 EDT
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
Comment 4 RHEL Product and Program Management 2011-01-11 15:54:08 EST
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.
Comment 5 RHEL Product and Program Management 2011-01-11 17:50:47 EST
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.
Comment 8 Mike Cao 2011-01-30 01:44:01 EST
Reproduced on 
# 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 

HugePages_Total:  3000
HugePages_Free:   2681
HugePages_Rsvd:      0

Excepted Results:
should 5GB of hugepage mem be used
Comment 11 Andrea Arcangeli 2011-08-07 09:06:49 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.