Bug 582282 - VM backed by hugepages does not preallocate its memory
Summary: VM backed by hugepages does not preallocate its memory
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.5
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Andrea Arcangeli
QA Contact: Virtualization Bugs
Depends On:
Blocks: Rhel5KvmTier2
TreeView+ depends on / blocked
Reported: 2010-04-14 14:44 UTC by David Juran
Modified: 2013-01-09 22:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-08-07 13:06:49 UTC

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

Description David Juran 2010-04-14 14:44:11 UTC
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 20:38:37 UTC
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 20:54:08 UTC
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 22:50:47 UTC
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 06:44:01 UTC
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 13:06:49 UTC
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.