FWIW I think kernel boot command line options should be the preferred way of allocating hugepages as its generally the most reliable way of doing it.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1643675 Title: hugepages for non-default pagesize need manual setup Status in libvirt package in Ubuntu: New Status in systemd package in Ubuntu: New Status in nova-compute package in Juju Charms Collection: Triaged Bug description: This is a amd64 xenial/mitaka deploy using 1607 charms release where I need to have 1G hugepages available for openstack/kvm. nova-compute charm should provide ways to ease e.g. 1G hugepages setup, currently only exposes a "hugepages" setting that ends setting vm.nr_hugepages for the node, but even after settings kernel cmdline parameters for 1G hugepages (hugepagesz=1G hugepages=128), is not usable by libvirt-bin: #1 systemd: Installs /lib/systemd/system/dev-hugepages.mount with default pagesize => no hugetblfs mount with (e.g.) pagesize=1G #2 libvirt-bin: Installs apparmor profile ("libvirt-qemu") which only allows: # for access to hugepages owner "/run/hugepages/kvm/libvirt/qemu/**" rw, owner "/dev/hugepages/libvirt/qemu/**" rw, => not possible to have other mount points for other pagesizes. I've workaround'd #1,#2 above by overriding systemd's by creating a /etc/systemd/system/dev-hugepages.mount with below extra line at [Mount] section: Options=pagesize=1G -> https://paste.ubuntu.com/23513048/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1643675/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp