On 09/02/16 16:25, "Chris Friesen" <chris.frie...@windriver.com> wrote:
>On 02/09/2016 04:20 AM, Daniel P. Berrange wrote: > >> It not actually a huge waste - in fact it is likely to be beneficial to the >> overall performance of your VM. You need to remember that there is no direct >> relationship between allocation of huge pages to KVM and usage of huge pages >> inside the guest OS - any combination is valid. In particular if you give >> huge pages to KVM, then this has a performance benefit to the guest, even if >> the guest OS doesn't use huge pages itself, because it increases the TLB hit >> rate in the host for memory accesses by the guest. Using huge pages inside >> the guest OS too, increases the TLB hit rate of the guest hardware further >> extending this performance benefit. As such hosts which are intended to use >> huge pages should have all their host memory allocated to the huge page pool, >> except for what is required to run the various host OS services. > >It's not very efficient to use 1G hugepages with instances having less than 1G >of RAM, and since you have to pre-allocate 1G pages at boot time it's hard to >know how much to allocate to 1G pages vs 2MB pages. > >If all your instances have RAM in multiples of 1G then that's not a problem, >of >course. We went for 2M huge pages in the end (http://openstack-in-production.blogspot.fr/2015/09/ept-huge-pages-and-benchmarking.html). I was surprised how much better this worked than THP, I guess the problem is that THP is applied after the allocation and thus pages can be mixed. We found it difficult to get a balanced NUMA configuration. A recent blog from Mirantis suggested that the problem was to do with BIOS shadowing settings as described in https://www.mirantis.com/blog/mirantis-openstack-7-0-nfvi-deployment-guide-huge-pages/. > >Chris > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev