Bug 465532 - RFE: libvirt should support KVM huge page backed memory
RFE: libvirt should support KVM huge page backed memory
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
Depends On:
Blocks: F12VirtTarget
  Show dependency treegraph
Reported: 2008-10-03 14:40 EDT by James Ralston
Modified: 2009-09-15 06:43 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 515285 (view as bug list)
Last Closed: 2009-09-15 06:43:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Ralston 2008-10-03 14:40:53 EDT
According to reports from KVM developers, backing a KVM virtual guest with hugetlbfs can improve the performance of guests up to 10%:


The steps described in the above link aren't too difficult, but at the minimum, virt-manager should support passing –mem-path to qemu-kvm (e.g., allowing you to specify the path to the hugetlbfs to use).

(It would be super cool and spiffy if virt-manager were to allow the user to setup the hugetlbfs automagically, but that's a lot more complex, and would probably require a reboot. Being able to support using an existing hugetlbfs by specifying its path would be a reasonable compromise and should be easy to implement.)
Comment 1 Daniel Berrange 2008-10-03 15:31:52 EDT
I definitely do not want to expose the -mem-path implementation detail to users or virt-manager. They simply do not have the knowledge neccessary to understand what this means, nor how to leverage it. If we're to make use of this capability we need to figure out a better way to handle it in libvirt and/or kvm, preferably such that it 'just works' as it does in Xen world without any admin config.

Changing to libvirt, because this definitely isn't the job of virt-manager
Comment 2 James Ralston 2008-10-06 21:55:38 EDT
Well, the thing about hugepages is, you pretty much have to allocate them at system startup.  But memory reserved for hugepages can't be used normally by regular processes.

Also, it's not clear that virtualization could be the exclusive user of hugepages; there might be other things that could want to use hugepages.

Honestly, I think to *really* do this right, there needs to be some sort of system startup hook to allocate hugepages and mount hugetlsfs in a standard location (e.g., /hugepages).  There also needs to be some sort of configuration program (e.g., system-config-memory) to set the amount of memory allocated as hugepages.  (Maybe that could be folder into an existing utility.)

Then, when starting a virtual guest, libvirt could inspect /proc/meminfo to see if enough non-reserved hugepages are available to satisfy the virtual guest's memory size.  If yes, then libvirt automatically includes –mem-path on the command line; if not, then it doesn't.

Optionally, libvirt could expose tunables to virt-manager, so that users could, say, fine-tune which virtual guests grab hugepages, limit the number of hugepages that libvirt will attempt to grab (e.g., if other processes in the system were also wanting to use hugepages), et. al.

Comment 3 Noura El hawary 2008-11-26 01:33:17 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 4 Mark McLoughlin 2009-08-04 03:23:29 EDT
Moving to rawhide since this is an RFE. See also:

Comment 5 Mark McLoughlin 2009-08-19 13:26:55 EDT
We're still planning on this for Fedora 12

See bug #515741 for a related kernel issue
Comment 6 Daniel Berrange 2009-08-26 11:00:49 EDT
Latest upstream patches

Comment 7 Daniel Berrange 2009-09-15 06:43:27 EDT
Merged upstream and in rawhide


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