<div dir="ltr">Good news, we waiting for it in Xena almost an year.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 15, 2023 at 11:27 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2023-05-15 at 23:07 +0300, Maksim Malchuk wrote:<br>
> There is 6 month this backport without review, since Sean Mooney gives +2.<br>
> The next rebase needed to solve merge conflict have cleaned +2 from review.<br>
<br>
yes it was blocked on a question regarding does this confirm to stable backprot policy.<br>
<br>
we do not backport features and while this was considreed a bugfix on master it was also<br>
acknoladged that it is also a little featureish<br>
<br>
we discussed this last weak in the nova team meeting and agree it could proceed.<br>
<br>
but as i noted in my last reply this will have no effect if you jsut have hw:numa_nodes=1<br>
<br>
without hw:cpu_policy=dedicated or hw:mem_page_size<br>
<br>
<br>
with enableing cpu pinnign or explcit page size we do not track per numa node cpu or memory usage<br>
in the host numa toplogy object for a given compute node.<br>
as such without any usage informational there is noting to we the numa nodes with.<br>
<br>
so packing_host_numa_cells_allocation_strategy=false will not make vms that request a numa<br>
toplogy without numa resouce be balanced between the numa nodes.<br>
<br>
you still need to resize the instance to a flavor that actully properly request memory or cpu pinging.<br>
<br>
> <br>
> On Mon, May 15, 2023 at 10:53 PM hai wu <<a href="mailto:haiwu.us@gmail.com" target="_blank">haiwu.us@gmail.com</a>> wrote:<br>
> <br>
> > This patch was backported:<br>
> > <a href="https://review.opendev.org/c/openstack/nova/+/805649" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/805649</a>. Once this is in<br>
> > place, new VMs always get assigned correctly to the numa node with<br>
> > more free memory. But when existing VMs (created with vm flavor with<br>
> > hw:numa_node=1 set) already running on numa node #0 got live migrated,<br>
> > it would always be stuck on numa node #0 after live migration.<br>
> > <br>
> > So it seems we would also need to set hw:mem_page_size=small on the vm<br>
> > flavor, so that new VMs created from that flavor would be able to land<br>
> > on different numa node other than node#0 after its live migration?<br>
> > <br>
> > On Mon, May 15, 2023 at 2:33 PM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
> > > <br>
> > > On Mon, 2023-05-15 at 13:03 -0500, hai wu wrote:<br>
> > > > > > Another question: Let's say a VM runs on one host's numa node #0.<br>
> > If<br>
> > > > > > we live-migrate this VM to another host, and that host's numa node<br>
> > #1<br>
> > > > > > has more free memory, is it possible for this VM to land on the<br>
> > other<br>
> > > > > > host's numa node #1?<br>
> > > > > yes it is<br>
> > > > > on newer relsese we will prefer to balance the load across numa nodes<br>
> > > > > on older release nova woudl fill the first numa node then move to<br>
> > the second.<br>
> > > > <br>
> > > > About the above point, it seems even with the numa patch back ported<br>
> > > > and in place, the VM would be stuck in its existing numa node. Per my<br>
> > > > tests, after its live migration, the VM will end up on the other<br>
> > > > host's numa node #0, even if numa node#1 has more free memory. This is<br>
> > > > not the case for newly built VMs.<br>
> > > > <br>
> > > > Is this a design issue?<br>
> > > if you are using a release that supprot numa live migration (train +)<br>
> > > <br>
> > <a href="https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/numa-aware-live-migration.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/numa-aware-live-migration.html</a><br>
> > > then the numa affintiy is recalulated on live migration however numa<br>
> > node 0 is prefered.<br>
> > > <br>
> > > as of xena [compute]/packing_host_numa_cells_allocation_strategy has<br>
> > been added to contol how vms are balanced acros numa nodes<br>
> > > in zed the default was changed form packing vms per host numa node to<br>
> > balancing vms between host numa nodes<br>
> > > <br>
> > <a href="https://docs.openstack.org/releasenotes/nova/zed.html#relnotes-26-0-0-stable-zed-upgrade-notes" rel="noreferrer" target="_blank">https://docs.openstack.org/releasenotes/nova/zed.html#relnotes-26-0-0-stable-zed-upgrade-notes</a><br>
> > > <br>
> > > even without the enhanchemt in xena and zed it was possible for the<br>
> > scheduler to select a numa node<br>
> > > <br>
> > > if you dont enable memory or cpu aware numa placment with<br>
> > > hw:mem_page_size or hw:cpu_policy=dedicated then it will always select<br>
> > numa 0<br>
> > > <br>
> > > if you do not request cpu pinnign or a specifc page size the sechudler<br>
> > cant properly select the host nuam node<br>
> > > and will alwasy use numa node 0. That is one of the reason i said that<br>
> > if hw:numa_nodes is set then hw:mem_page_size shoudl be set.<br>
> > > <br>
> > > from a nova point of view using  numa_nodes without mem_page_size is<br>
> > logically incorrect as you asked for<br>
> > > a vm to be affinites to n host numa nodes but did not enable numa aware<br>
> > memory scheduling.<br>
> > > <br>
> > > we unfortnally cant provent this in the nova api without breaking<br>
> > upgrades for everyone who has made this mistake.<br>
> > > we woudl need to force them to resize all affected instances which means<br>
> > guest downtime.<br>
> > > the other issue si multiple numa nodes are supproted by Hyper-V but they<br>
> > do not supprot mem_page_size<br>
> > > <br>
> > > we have tried to document this in the past but never agreed on how<br>
> > becasuse it subtel and requries alot of context.<br>
> > > the tl;dr is if the instace has a numa toplogy it should have<br>
> > mem_page_size set in the image or flavor but<br>
> > > we never foudn a good place to capture that.<br>
> > > <br>
> > > > <br>
> > > > On Thu, May 11, 2023 at 2:42 PM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>><br>
> > wrote:<br>
> > > > > <br>
> > > > > On Thu, 2023-05-11 at 08:40 -0500, hai wu wrote:<br>
> > > > > > Ok. Then I don't understand why 'hw:mem_page_size' is not made the<br>
> > > > > > default in case if hw:numa_node is set. There is a huge<br>
> > disadvantage<br>
> > > > > > if not having this one set (all existing VMs with hw:numa_node set<br>
> > > > > > will have to be taken down for resizing in order to get this one<br>
> > > > > > right).<br>
> > > > > there is an upgrade impact to changign the default.<br>
> > > > > its not impossibel to do but its complicated if we dont want to<br>
> > break exisitng deployments<br>
> > > > > we woudl need to recored a value for eveny current instance that was<br>
> > spawned before<br>
> > > > > this default was changed that had hw:numa_node without<br>
> > hw:mem_page_size so they kept the old behavior<br>
> > > > > and make sure that is cleared when the vm is next moved so it can<br>
> > have the new default<br>
> > > > > after a live migratoin.<br>
> > > > > > <br>
> > > > > > I could not find this point mentioned in any existing Openstack<br>
> > > > > > documentation: that we would have to set hw:mem_page_size<br>
> > explicitly<br>
> > > > > > if hw:numa_node is set. Also this slide at<br>
> > > > > > <a href="https://www.linux-kvm.org/images/0/0b/03x03-Openstackpdf.pdf" rel="noreferrer" target="_blank">https://www.linux-kvm.org/images/0/0b/03x03-Openstackpdf.pdf</a> kind<br>
> > of<br>
> > > > > > indicates that hw:mem_page_size `Default to small pages`.<br>
> > > > > it defaults to unset.<br>
> > > > > that results in small pages by default but its not the same as<br>
> > hw:mem_page_size=small<br>
> > > > > or hw:mem_page_size=any.<br>
> > > > > <br>
> > > > > <br>
> > > > > > <br>
> > > > > > Another question: Let's say a VM runs on one host's numa node #0.<br>
> > If<br>
> > > > > > we live-migrate this VM to another host, and that host's numa node<br>
> > #1<br>
> > > > > > has more free memory, is it possible for this VM to land on the<br>
> > other<br>
> > > > > > host's numa node #1?<br>
> > > > > yes it is<br>
> > > > > on newer relsese we will prefer to balance the load across numa nodes<br>
> > > > > on older release nova woudl fill the first numa node then move to<br>
> > the second.<br>
> > > > > > <br>
> > > > > > On Thu, May 11, 2023 at 4:25 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>><br>
> > wrote:<br>
> > > > > > > <br>
> > > > > > > On Wed, 2023-05-10 at 15:06 -0500, hai wu wrote:<br>
> > > > > > > > Is it possible to update something in the Openstack database<br>
> > for the<br>
> > > > > > > > relevant VMs in order to do the same, and then hard reboot the<br>
> > VM so<br>
> > > > > > > > that the VM would have this attribute?<br>
> > > > > > > not really adding the missing hw:mem_page_size requirement to<br>
> > the flavor chagnes the<br>
> > > > > > > requirements for node placement and numa affinity<br>
> > > > > > > so you really can only change this via resizing the vm to a new<br>
> > flavor<br>
> > > > > > > > <br>
> > > > > > > > On Wed, May 10, 2023 at 2:47 PM Sean Mooney <<br>
> > <a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
> > > > > > > > > <br>
> > > > > > > > > On Wed, 2023-05-10 at 14:22 -0500, hai wu wrote:<br>
> > > > > > > > > > So there's no default value assumed/set for<br>
> > hw:mem_page_size for each<br>
> > > > > > > > > > flavor?<br>
> > > > > > > > > > <br>
> > > > > > > > > correct this is a known edgecase in the currnt design<br>
> > > > > > > > > hw:mem_page_size=any would be a resonable default but<br>
> > > > > > > > > techinially if just set hw:numa_nodes=1 nova allow memory<br>
> > over subscription<br>
> > > > > > > > > <br>
> > > > > > > > > in pratch if you try to do that you will almost always end<br>
> > up with vms<br>
> > > > > > > > > being killed due to OOM events.<br>
> > > > > > > > > <br>
> > > > > > > > > so from a api point of view it woudl be a change of behvior<br>
> > for use to default<br>
> > > > > > > > > to hw:mem_page_size=any but i think it would be the correct<br>
> > thign to do for operators<br>
> > > > > > > > > in the long run.<br>
> > > > > > > > > <br>
> > > > > > > > > i could bring this up with the core team again but in the<br>
> > past we<br>
> > > > > > > > > decided to be conservitive and just warn peopel to alwasy set<br>
> > > > > > > > > hw:mem_page_size if using numa affinity.<br>
> > > > > > > > > <br>
> > > > > > > > > >  Yes <a href="https://bugs.launchpad.net/nova/+bug/1893121" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1893121</a> is<br>
> > critical<br>
> > > > > > > > > > when using hw:numa_nodes=1.<br>
> > > > > > > > > > <br>
> > > > > > > > > > I did not hit an issue with 'hw:mem_page_size' not set,<br>
> > maybe I am<br>
> > > > > > > > > > missing some known test cases? It would be very helpful to<br>
> > have a test<br>
> > > > > > > > > > case where I could reproduce this issue with<br>
> > 'hw:numa_nodes=1' being<br>
> > > > > > > > > > set, but without 'hw:mem_page_size' being set.<br>
> > > > > > > > > > <br>
> > > > > > > > > > How to ensure this one for existing vms already running<br>
> > with<br>
> > > > > > > > > > 'hw:numa_nodes=1', but without 'hw:mem_page_size' being<br>
> > set?<br>
> > > > > > > > > you unfortuletly need to resize the instance.<br>
> > > > > > > > > tehre are some image porpeties you can set on an instance<br>
> > via nova-manage<br>
> > > > > > > > > but you cannot use nova-mange to update the enbedd flavor<br>
> > and set this.<br>
> > > > > > > > > <br>
> > > > > > > > > so you need to define a new flavour and resize.<br>
> > > > > > > > > <br>
> > > > > > > > > this is the main reason we have not changed the default as<br>
> > it may requrie you to<br>
> > > > > > > > > move instnace around if there placement is now invalid now<br>
> > that per numa node memory<br>
> > > > > > > > > allocatons are correctly being accounted for.<br>
> > > > > > > > > <br>
> > > > > > > > > if it was simple to change the default without any enduser<br>
> > or operator impact we would.<br>
> > > > > > > > > <br>
> > > > > > > > > <br>
> > > > > > > > > <br>
> > > > > > > > > > <br>
> > > > > > > > > > On Wed, May 10, 2023 at 1:47 PM Sean Mooney <<br>
> > <a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > if you set hw:numa_nodes there are two things you should<br>
> > keep in mind<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > first if hw:numa_nodes si set to any value incluing<br>
> > hw:numa_nodes=1<br>
> > > > > > > > > > > then hw:mem_page_size shoudl also be defiend on the<br>
> > falvor.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > if you dont set hw:mem_page_size then the vam will be<br>
> > pinned to a host numa node<br>
> > > > > > > > > > > but the avaible memory on the host numa node will not be<br>
> > taken into account<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > only the total free memory on the host so this almost<br>
> > always results in VMs being killed by the OOM reaper<br>
> > > > > > > > > > > in the kernel.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > i recomend setting hw:mem_page_size=small<br>
> > hw:mem_page_size=large or hw:mem_page_size=any<br>
> > > > > > > > > > > small will use your kernels default page size for guest<br>
> > memory, typically this is 4k pages<br>
> > > > > > > > > > > large will use any pages size other then the smallest<br>
> > that is avaiable (i.e. this will use hugepages)<br>
> > > > > > > > > > > and any will use small pages but allow the guest to<br>
> > request hugepages via the hw_page_size image property.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > hw:mem_page_size=any is the most flexable as a result<br>
> > but generally i recommend using  hw:mem_page_size=small<br>
> > > > > > > > > > > and having a seperate flavor for hugepages. its really<br>
> > up to you.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > <br>
> > > > > > > > > > > the second thing to keep in mind is using expict numa<br>
> > toplolig8ies including hw:numa_nodes=1<br>
> > > > > > > > > > > disables memory oversubsctipion.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > so you will not be able ot oversubscibe the memory on<br>
> > the host.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > in general its better to avoid memory oversubscribtion<br>
> > anyway but jsut keep that in mind.<br>
> > > > > > > > > > > you cant jsut allocate a buch of swap space and run vms<br>
> > at a 2:1 or higher memory over subscription ratio<br>
> > > > > > > > > > > if you are using numa affinity.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > <br>
> > <a href="https://that.guru/blog/the-numa-scheduling-story-in-nova/" rel="noreferrer" target="_blank">https://that.guru/blog/the-numa-scheduling-story-in-nova/</a><br>
> > > > > > > > > > > and<br>
> > > > > > > > > > > <a href="https://that.guru/blog/cpu-resources-redux/" rel="noreferrer" target="_blank">https://that.guru/blog/cpu-resources-redux/</a><br>
> > > > > > > > > > > <br>
> > > > > > > > > > > are also good to read<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > i do not think stephen has a dedicated block on the<br>
> > memory aspect<br>
> > > > > > > > > > > but <a href="https://bugs.launchpad.net/nova/+bug/1893121" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1893121</a> covers<br>
> > some of the probelem that only setting<br>
> > > > > > > > > > > hw:numa_nodes=1 will casue.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > if you have vms with hw:numa_nodes=1 set and you do not<br>
> > have hw:mem_page_size set in the falvor or<br>
> > > > > > > > > > > hw_mem_page_size set in the image then that vm is not<br>
> > configure properly.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > On Wed, 2023-05-10 at 11:52 -0600, Alvaro Soto wrote:<br>
> > > > > > > > > > > > Another good resource =)<br>
> > > > > > > > > > > > <br>
> > > > > > > > > > > > <a href="https://that.guru/blog/cpu-resources/" rel="noreferrer" target="_blank">https://that.guru/blog/cpu-resources/</a><br>
> > > > > > > > > > > > <br>
> > > > > > > > > > > > On Wed, May 10, 2023 at 11:50 AM Alvaro Soto <<br>
> > <a href="mailto:alsotoes@gmail.com" target="_blank">alsotoes@gmail.com</a>> wrote:<br>
> > > > > > > > > > > > <br>
> > > > > > > > > > > > > I don't think so.<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > ~~~<br>
> > > > > > > > > > > > > The most common case will be that the admin only<br>
> > sets hw:numa_nodes and<br>
> > > > > > > > > > > > > then the flavor vCPUs and memory will be divided<br>
> > equally across the NUMA<br>
> > > > > > > > > > > > > nodes. When a NUMA policy is in effect, it is<br>
> > mandatory for the instance's<br>
> > > > > > > > > > > > > memory allocations to come from the NUMA nodes to<br>
> > which it is bound except<br>
> > > > > > > > > > > > > where overriden by hw:numa_mem.NN.<br>
> > > > > > > > > > > > > ~~~<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > Here are the implementation documents since Juno<br>
> > release:<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > <br>
> > <a href="https://opendev.org/openstack/nova-specs/src/branch/master/specs/juno/implemented/virt-driver-numa-placement.rst" rel="noreferrer" target="_blank">https://opendev.org/openstack/nova-specs/src/branch/master/specs/juno/implemented/virt-driver-numa-placement.rst</a><br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > <br>
> > <a href="https://opendev.org/openstack/nova-specs/commit/45252df4c54674d2ac71cd88154af476c4d510e1" rel="noreferrer" target="_blank">https://opendev.org/openstack/nova-specs/commit/45252df4c54674d2ac71cd88154af476c4d510e1</a><br>
> > > > > > > > > > > > > ?<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > On Wed, May 10, 2023 at 11:31 AM hai wu <<br>
> > <a href="mailto:haiwu.us@gmail.com" target="_blank">haiwu.us@gmail.com</a>> wrote:<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > > Is there any concern to enable 'hw:numa_nodes=1'<br>
> > on all flavors, as<br>
> > > > > > > > > > > > > > long as that flavor can fit into one numa node?<br>
> > > > > > > > > > > > > > <br>
> > > > > > > > > > > > > > <br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > --<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > Alvaro Soto<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > > *Note: My work hours may not be your work hours.<br>
> > Please do not feel the<br>
> > > > > > > > > > > > > need to respond during a time that is not convenient<br>
> > for you.*<br>
> > > > > > > > > > > > > <br>
> > ----------------------------------------------------------<br>
> > > > > > > > > > > > > Great people talk about ideas,<br>
> > > > > > > > > > > > > ordinary people talk about things,<br>
> > > > > > > > > > > > > small people talk... about other people.<br>
> > > > > > > > > > > > > <br>
> > > > > > > > > > > > <br>
> > > > > > > > > > > > <br>
> > > > > > > > > > > <br>
> > > > > > > > > > <br>
> > > > > > > > > <br>
> > > > > > > > <br>
> > > > > > > <br>
> > > > > > <br>
> > > > > <br>
> > > > <br>
> > > <br>
> > <br>
> > <br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div style="font-family:arial;font-size:small">Regards,<br></div><div style="font-family:arial;font-size:small">Maksim Malchuk</div><div style="font-family:arial;font-size:small"><br></div></div></div>