<div dir="ltr">Hello/<div>After chasing links and your examples, I found this example is good for beginners like me, I want to show that for previous people.</div><div><br></div><div><a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/configuring_the_compute_service_for_instance_creation/index#proc_configuring-compute-nodes-for-cpu-pinning_cpu-pinning">https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/configuring_the_compute_service_for_instance_creation/index#proc_configuring-compute-nodes-for-cpu-pinning_cpu-pinning</a><br></div><div><br></div><div>Thank you much.</div><div><br><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Nguyen Huu Khoi<br></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 23, 2023 at 9:54 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 Thu, 2023-03-23 at 14:51 +0100, Dmitriy Rabotyagov wrote:<br>
> Just in case, you DO have options to control cpu and ram reservation<br>
> for the hypervisor. It's just more about that, that it's not the best<br>
> way to do it, especially if you're overcommitting, as things in real<br>
> life are more complicated then just defining the amount of reserved<br>
> CPUs.<br>
> <br>
> For example, if you have cpu_allocation_ratio set to 3, then you're<br>
> getting 3 times more CPUs to signup VMs then you actually have<br>
> (cores*sockets*threads*cpu_allocation_ratio). With that you really<br>
> can't set any decent amount of reserved CPUs that will 100% ensure<br>
> that hypervisor will be able to gain required resources at any given<br>
> time. So with that approach the only option is to disable cpu<br>
> overcommit, but even then you might get CPU in socket 1 fully utilized<br>
> which might have negative side-effects for the hypervisor.<br>
> <br>
> And based on that, as Sean has mentioned, you can tell nova to<br>
> explicitly exclude specific cores from being utilized, which will make<br>
> them reserved for the hypervisor.<br>
yep exactly.<br>
without geting into all the details the host reserved cpu option was added in the really early days and then vcpu_pin_set was<br>
added to adress the fact that the existing option didnt really work the way peopel wanted.<br>
it was later used for cpu pinning and we realise we wanted to have 2 sepreate pools of cpus<br>
<br>
cpu_shared_set for shared core useed by floating vms (anything with out hw:cpu_policy=dedicated) and<br>
cpu_dedicated_set for explictlly pinned vms.<br>
<br>
in general using cpu_shared_set and cpu_dedicated_set is a much more intitive way to resver cores since you get to select exaction which<br>
cores can be used for nova vms.<br>
<br>
that allows you do the use systemd or other tools like taskset  to affiites nova-cpu or libvirtd or  sshd to run  on core that wont have vms<br>
that prevents the vms form staving those host process of cpu resouces.<br>
> <br>
> чт, 23 мар. 2023 г. в 14:35, Nguyễn Hữu Khôi <<a href="mailto:nguyenhuukhoinw@gmail.com" target="_blank">nguyenhuukhoinw@gmail.com</a>>:<br>
> > <br>
> > Ok. I will try to understand it. I will let you know when I get it.<br>
> > Many thanks for your help. :)<br>
> > <br>
> > On Thu, Mar 23, 2023, 8:14 PM Dmitriy Rabotyagov <<a href="mailto:noonedeadpunk@gmail.com" target="_blank">noonedeadpunk@gmail.com</a>> wrote:<br>
> > > <br>
> > > Just to double check with you, given that you have<br>
> > > cpu_overcommit_ratio>1, 2 sockets and HT enabled, and each CPU has 32<br>
> > > physical cores, then it should be defined like:<br>
> > > <br>
> > > [compute]<br>
> > > cpu_shared_set="2-32,34-64,66-96,98-128"?<br>
> > > <br>
> > > > in general you shoudl reserve the first core on each cpu socket for the host os.<br>
> > > > if you use hyperthreading then both hyperthread of the first cpu core on each socket shoudl be omitted<br>
> > > > form the cpu_shared_set and cpu_dedicated_set<br>
> > > <br>
> > > чт, 23 мар. 2023 г. в 13:12, Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>>:<br>
> > > > <br>
> > > > generally you should not<br>
> > > > you can use it but the preferd way to do this is use<br>
> > > > cpu_shared_set and cpu_dedicated_set (in old releases you would have used vcpu_pin_set)<br>
> > > > <a href="https://docs.openstack.org/nova/latest/configuration/config.html#compute.cpu_shared_set" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/config.html#compute.cpu_shared_set</a><br>
> > > > <a href="https://docs.openstack.org/nova/latest/configuration/config.html#compute.cpu_dedicated_set" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/config.html#compute.cpu_dedicated_set</a><br>
> > > > <br>
> > > > if you dont need cpu pinning just use cpu_share_set to spcify the cores that can be sued for floatign vms<br>
> > > > when you use cpu_shared_set and cpu_dedicated_set any cpu not specified are reseved for host use.<br>
> > > > <br>
> > > > <a href="https://that.guru/blog/cpu-resources/" rel="noreferrer" target="_blank">https://that.guru/blog/cpu-resources/</a> and <a href="https://that.guru/blog/cpu-resources-redux/" rel="noreferrer" target="_blank">https://that.guru/blog/cpu-resources-redux/</a><br>
> > > > <br>
> > > > have some useful info but that mostly looking at it form a cpu pinning angel althoguh the secon one covers cpu_shared_set,<br>
> > > > <br>
> > > > the issue with usein<br>
> > > > <a href="https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_cpus" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_cpus</a><br>
> > > > <br>
> > > > is that you have to multiple the number of cores that are resverved by the<br>
> > > > <a href="https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.cpu_allocation_ratio" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.cpu_allocation_ratio</a><br>
> > > > <br>
> > > > which means if you decide to manage that via placement api by using<br>
> > > > <a href="https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.initial_cpu_allocation_ratio</a> instead<br>
> > > > then you need to update your nova.conf to modify the reservationfi you change the allocation ratio.<br>
> > > > <br>
> > > > if instead you use cpu_shared_set and cpu_dedicated_set<br>
> > > > you are specifying exactly which cpus nova can use and the allocation ration nolonger needs to be conisderd.<br>
> > > > <br>
> > > > in general you shoudl reserve the first core on each cpu socket for the host os.<br>
> > > > if you use hyperthreading then both hyperthread of the first cpu core on each socket shoudl be omitted<br>
> > > > form the cpu_shared_set and cpu_dedicated_set<br>
> > > > <br>
> > > > <br>
> > > > <br>
> > > > On Thu, 2023-03-23 at 14:44 +0700, Nguyễn Hữu Khôi wrote:<br>
> > > > > Hello guys.<br>
> > > > > I am trying google for nova host cpu reserve to prevent host overload but I<br>
> > > > > cannot find any resource about it. Could you give me some information?<br>
> > > > > Thanks.<br>
> > > > > Nguyen Huu Khoi<br>
> > > > <br>
> > > > <br>
> <br>
<br>
<br>
</blockquote></div>