Bug 582282

Summary: VM backed by hugepages does not preallocate its memory
Product: Red Hat Enterprise Linux 5 Reporter: David Juran <djuran>
Component: kvmAssignee: Andrea Arcangeli <aarcange>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 5.5CC: acathrow, bcao, francois, gcosta, hannes, liko, llim, tburke, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-07 13:06:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 580948    
Attachments:
Description Flags
test machine none

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 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

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 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 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
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

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.