)]}'
{"specs/ocata/approved/virt-hugepages-per-guest-numa-nodes.rst":[{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4291923afe1be6a785ea36ce9bb0a9496d649b4f","unresolved":false,"context_lines":[{"line_number":32,"context_line":"have the requirement to configure different pagesize per guest NUMA"},{"line_number":33,"context_line":"nodes for best performance or for conservative. E.g: Running DPDK poll"},{"line_number":34,"context_line":"mode driver inside guest. Guest can have multiple NUMA nodes but uses"},{"line_number":35,"context_line":"hugepages only from one NUMA node."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Proposed change"},{"line_number":38,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_db132f5b","line":35,"updated":"2016-09-22 15:58:40.000000000","message":"The fact that a guest OS may not use huge pages in one of the virtual NUMA nodes, does not imply that we should not use huge pages for backing memory.\n\nIt is still a major performance benefit to back guest RAM with huge pages, even if the guest OS itself will not use huge pages inside.\n\nSo this use case is not compelling. It will add extra complexity to Nova, in order to make performance of the guest worse.","commit_id":"e66a4fdf7bc117e9019db38738dd43aff582354b"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4291923afe1be6a785ea36ce9bb0a9496d649b4f","unresolved":false,"context_lines":[{"line_number":66,"context_line":"size, the NUMA node 1 is going to request 2MiB hugepages size, the"},{"line_number":67,"context_line":"NUMA node 2 is going to request the smallest page size avalabile on"},{"line_number":68,"context_line":"the host (4KiB for x86 arch) and the NUMA node 3 the largest hugepages"},{"line_number":69,"context_line":"size available."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Alternatives"},{"line_number":72,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a8bc5a2_fbf62bd6","line":69,"updated":"2016-09-22 15:58:40.000000000","message":"Allowing guests to use a mixture of huge and small pages will significantly complicate both nova code, and host deployment. Currently when using huge pages, we require a dedicated host aggregrate for compute nodes running huge page guests. Those compute nodes have nearly all their memory pre-allocated to huge pages, since they\u0027ll only ever run huge page guests.\n\nIf you try to run a guest which does not want huge pages, or only uses huge pages for a subset of its RAM, then you can no longer just reserve all host RAM for huge pages when the compute node is deployed. Either the admin has to guess at how much RAM to reserve for huge pages, or nova has to dynamically release \u0026 acquire huge pages. The latter will increasingly fail over time, as memory gets fragmented.\n\nIOW, I strongly believe we want to keep a setup where a compute node either does small pages, or huge pages, and does *not* try to mix the two either within a guest, or between guests.\n\nTrying to allow a guest to have a mixture of different huge pages sizes hits a similar problem - as the admin is forced to decide how many 1 GB and how many 2MB pages to reserve, or nova has to dynamically swap between them, again hitting problems with fragmentation of RAM.","commit_id":"e66a4fdf7bc117e9019db38738dd43aff582354b"}]}