similar to: [PATCH 2/2] PV hugepages - Linux patch

This is the latest version of a patch that adds hugepage support to the Xen hypervisor in a PV environment. It is against the latest xen-unstable tree on xenbits.xensource.com. I believe this version addresses the comments made about the previous version of the patch. Hugepage support must be enabled via the hypervisor command line option "allowhugepage". It assumes the guest

This patch enables support of hugepages in a pv Xen environment. It is against the latest xen unstable tree on http://xenbits.xensource.com. The patch assumes the guest is passing a physically aligned hugepage. It does reference counting on all the underlying pages. Dave McCracken Oracle Corp. _______________________________________________ Xen-devel mailing list

Here is a set of small patches that enables hugetlb on PV machines. They are against xen-unstable and linux-2.6.18-xen. The patches are specifically for x86_64. I originally had these patches working back in May, but recently for some reason my machine now refuses to boot the baseline xen-unstable, so I''ve been unable to verify them. However, they should still work. Comments, bug

The PV superpage mapping feature has been in the hypervisor for a while now, but I''m not away of any use of this feature by an upstream guest kernel (e.g., and primarily of interest, pv_ops Linux). Am I mistaken, or is anyone looking into or interested in this? If the feature is unused we should remove it from the hypervisor in this development cycle, as it''s untested and is

Hello, I have a CentOS 7 installation on baremetal with 2 CPUs, 10 cores each and HT enabled, 128 GB RAM. The system has transparent hugetables enabled. cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never The system reports anonymous hugepages pages usage and a size of hugepage of 2048Kb cat /proc/meminfo |grep -i hugepages|grep AnonHugePages AnonHugePages: 35491840 kB

First I'll quickly summarize my understanding of how to configure numa... In "//memoryBacking/hugepages/page[@nodeset]" I am telling libvirt to use hugepages for the guest, and to get those hugepages from a particular host NUMA node. In "//numatune/memory[@nodeset]" I am telling libvirt to pin the memory allocation to the guest from a particular host numa node. In

On Tue, Feb 10, 2015 at 1:14 AM, Michal Privoznik <mprivozn@redhat.com> wrote: > On 09.02.2015 18:19, G. Richard Bellamy wrote: >> First I'll quickly summarize my understanding of how to configure numa... >> >> In "//memoryBacking/hugepages/page[@nodeset]" I am telling libvirt to >> use hugepages for the guest, and to get those hugepages from a

On 09.02.2015 18:19, G. Richard Bellamy wrote: > First I'll quickly summarize my understanding of how to configure numa... > > In "//memoryBacking/hugepages/page[@nodeset]" I am telling libvirt to > use hugepages for the guest, and to get those hugepages from a > particular host NUMA node. No, @nodeset refers to guest NUMA nodes. > > In

We have implemented hugepage support for guests in following manner In our implementation we added a parameter hugepage_num which is specified in the config file of the DomU. It is the number of hugepages that the guest is guaranteed to receive whenever the kernel asks for hugepage by using its boot time parameter or reserving after booting (eg. Using echo XX > /proc/sys/vm/nr_hugepages).

Regarding fine tuning my explanation about what system does de actual mounting of Hugepages, you?re probably right?. Thanks for the correction. On upstart systems (like Ubuntu) the mounting of Hugepages is done by the init script qemu-kvm.conf Van: G. Richard Bellamy [mailto:rbellamy at pteradigm.com] Verzonden: zondag 1 februari 2015 0:02 Aan: Dominique Ramaekers CC: libvirt-users at

*facepalm* Now that I'm re-reading the documentation it's obvious that <page/> and @nodeset are for the guest, "This tells the hypervisor that the guest should have its memory allocated using hugepages instead of the normal native page size." Pretty clear there. Thank you SO much for the guidance, I'll return to my tweaking. I'll report back here with my results.

Did you create a mount for the hugepages? If you did, that's maybe the problem. I did that also at first but with libvirt it isn't necessary and in my case, it broke hugepages... If I'm not mistaking, libvirt takes care of the hugepages mount. A while ago, I've written a wiki to use hugepages in libvirt and Ubuntu. https://help.ubuntu.com/community/KVM%20-%20Using%20Hugepages

On Fri, Jan 30, 2015 at 03:33:43PM -0800, G. Richard Bellamy wrote: >Hello All, > >I'm trying to enable hugepages, I've turned off THP (Transparent Huge >Pages), and enabled hugepages in memoryBacking, and set my 2MB >hugepages count via sysctl. > >I'm getting "libvirtd[5788]: Failed to autostart VM 'atlas': internal >error: Unable to find any

On 04.02.2015 01:59, G. Richard Bellamy wrote: > As I mentioned, I got the instances to launch... but they're only > taking HugePages from "Node 0", when I believe my setup should pull > from both nodes. > > [atlas] http://sprunge.us/FSEf > [prometheus] http://sprunge.us/PJcR [pasting interesting nits from both XMLs] <domain type='kvm'

As I mentioned, I got the instances to launch... but they're only taking HugePages from "Node 0", when I believe my setup should pull from both nodes. [atlas] http://sprunge.us/FSEf [prometheus] http://sprunge.us/PJcR 2015-02-03 16:51:48 root@eanna i ~ # virsh start atlas Domain atlas started 2015-02-03 16:51:58 root@eanna i ~ # virsh start prometheus Domain prometheus started

On 20.02.2015 21:32, G. Richard Bellamy wrote: > <snip/> > > I've modified my config [1] based on my understanding, and am running > into a new error. Basically I'm hitting the oom-killer [2] even though > the hard_limit [3] of memtune is below the total number of hugepages > set for that NUMA nodeset. > Just drop the hard_limit. It's a blackbox we should

Yeah, Dominique, your wiki was one of the many docs I read through before/during/after starting down this primrose path... thanks for writing it. I'm an Arch user, and I couldn't find anything to indicate qemu, as its compiled for Arch, will look in /etc/default/qemu-kvm. And now that I've got the right page size, the instances are starting... The reason I want to use the page element

Hello All, I'm trying to enable hugepages, I've turned off THP (Transparent Huge Pages), and enabled hugepages in memoryBacking, and set my 2MB hugepages count via sysctl. I'm getting "libvirtd[5788]: Failed to autostart VM 'atlas': internal error: Unable to find any usable hugetlbfs mount for 16777216 KiB" where atlas is one of my guests and 16777216 KiB is the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thanks a lot you two, yes hugetlbfs is not mounted, when libvirtd is started… It was a long night. Did put it to fstab and since I do not allocate them on regular boots, it won’t eat my ram (that was the main consideration for doing it like this). As a last means before going to sleep, I added <qemu:arg value='-numa'/>

hi, I tried to make huge page request in Fedora x86_64 PV guest using xen 4.1 unstable and it crashed(crash info given below) I had enabled superpages in config file I had also set hugepages parameter at boot time for the PV Dom U By excuting # cat /proc/mem_info | grep Huge gave me that there are 10 free huge pages available , still the domain crashed. [ 86.403654] BUG: unable to handle