<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Shewale, Bhagyashri <<a href="mailto:Bhagyashri.Shewale@nttdata.com">Bhagyashri.Shewale@nttdata.com</a>> 于2019年6月19日周三 上午11:01写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div id="gmail-m_-5115961656861618757divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p style="margin-top:0px;margin-bottom:0px"></p>
<p style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)"></p>
<p style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">Hi All,</p>
<p style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69);min-height:14px">
<br>
</p>
<p style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">After all discussions on mailing thread, I would like to summarize concluded points as under:-</p>
<ol style="list-style-type:decimal">
<li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">If operator sets ``vcpu_pin_set`` in Stein and upgrade it to Train or ``vcpu_pin_set`` is set on a new compute node, then both VCPU and PCPU inventory should be reported to placement.</li><li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">User can’t request both ``resources:PCPU`` and ``resources:VCPU`` in a single request for Train release. And in future<span class="gmail-m_-5115961656861618757Apple-converted-space"> 
</span>‘U’ release, user can request both<span class="gmail-m_-5115961656861618757Apple-converted-space">  </span>
``resources:PCPU`` and ``resources:VCPU`` in a single request.</li><li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">In “U” release,<span class="gmail-m_-5115961656861618757Apple-converted-space"> 
</span>“vcpu_pin_set” config option will be removed. In this case, operator will either need to set “cpu_shared_set” or “cpu_dedicated_set” accordingly on old compute nodes and on new compute nodes, operator can set both the config option “cpu_shared_set” and<span class="gmail-m_-5115961656861618757Apple-converted-space"> 
</span>“cpu_dedicated_set” if required.</li><li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">In Train release, operator will also need to continue retaining the same behavior of host aggregates as that of Stein to differentiate between Numa-awared compute host:</li><ul style="list-style-type:disc">
<li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)"><span style="font:10px Menlo"></span>Hosts meant for pinned<span class="gmail-m_-5115961656861618757Apple-converted-space"> 
</span>instances should be part of the aggregate with metadata “pinned=True”</li><li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)"><span style="font:10px Menlo"></span>Hosts meant for non-pinned<span class="gmail-m_-5115961656861618757Apple-converted-space"> 
</span>instances should be part of the aggregate with metadata “pinned=False”</li></ul>
<li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">In Train release, old flavor can be used as is in which case scheduler pre-filter will map it to the next syntax “resources:PCPU” in case cpu_policy=dedicated.</li></ol></div></div></blockquote><div>+1 all above </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-5115961656861618757divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><ol style="list-style-type:decimal"><li style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">In Train release, new flavor syntax “resources:PCPU=1 will be accepted<span class="gmail-m_-5115961656861618757Apple-converted-space"> 
</span>in flavor extra specs but in this case we expect operator will set “aggregate_instance_extra_specs:pinned=True” in flavor extra specs and the hosts are part of the aggregate which has metadata “pinned=True”.</li></ol></div></div></blockquote><div>If the user finished the upgrade, and switch to dedicated_cpu_set and shared_cpu_set, then he needn't aggregate anymore.</div><div><br></div><div>For using resources:PCPU directly, I'm not sure. I have talk with Sean few days ago, we both think that we shouldn't allow the user using "resources" extra spec directly. Thinking about the future, we have numa on placement, the resources and traits extra spec can't express all the guest numa info. Like which numa node is the first one. And it is hard to parse the guest numa topo from those extra spec, and it isn't human readable. Also "hw:" provides some abstraction than resources/traits extra spec, allow us to do some upgrade without asking user update their flavor. But this isn't critical problem for now, until we have numa on placement.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-5115961656861618757divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<p style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">Regards,</p>
<p style="margin:0px;font:12px "Helvetica Neue";color:rgb(69,69,69)">Bhagyashri Shewale</p>
<br>
<p></p>
<p></p>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-5115961656861618757divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Stephen Finucane <<a href="mailto:sfinucan@redhat.com" target="_blank">sfinucan@redhat.com</a>><br>
<b>Sent:</b> Tuesday, June 18, 2019 6:51:15 PM<br>
<b>To:</b> Shewale, Bhagyashri; <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a><br>
<b>Subject:</b> Re: [nova] Spec: Standardize CPU resource tracking</font>
<div> </div>
</div>
<div class="gmail-m_-5115961656861618757BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="gmail-m_-5115961656861618757PlainText">On Tue, 2019-06-18 at 06:41 +0000, Shewale, Bhagyashri wrote:<br>
> > As above, ignore 'cpu_shared_set' but issue a warning. Use the value of<br>
> > ‘vcpu_pin_set' to report both VCPU and PCPU inventory. Note that<br>
> > ‘vcpu_pin_set' is already used to calculate VCPU inventory.<br>
> <br>
> As mentioned in the spec, If operator sets the ``vcpu_pin_set`` in<br>
> the Stein and upgrade to Train then both VCPU and PCPU inventory<br>
> should be reported in placement. <br>
> <br>
> As on current master (Stein) if operator sets ``vpcu_pin_set=0-3`` on<br>
> Compute node A and adds that node A into the host aggregate say<br>
> “agg1” having metadata ``pinned=true``, then it allows to create <br>
> both pinned and non-pinned instances which is known big issue.<br>
> Create instance A having flavor extra specs<br>
> ("aggregate_instance_extra_specs:pinned": "true") then instance A<br>
> will float on cpus 0-3<br>
> Create the instance B having flavor extra specs<br>
> ("aggregate_instance_extra_specs:pinned": "true", "hw:cpu_policy":<br>
> "dedicated") then instance B will be pinned to one of the cpu say 0.<br>
> Now, operator will do the upgrade (Stein to Train), nova compute will<br>
> report both VCPU and PCPU inventory. In this case if<br>
> cpu_allocation_ratio is 1, then total PCPU available will be 4<br>
> (vpcu_pin_set=0-3) and VCPU will also be 4. And this will allow user<br>
> to create maximum of 4 instances with flavor extra specs<br>
> ``resources:PCPU=1`` and 4 instances with flavor extra specs<br>
> ``resources:VCPU=1``.<br>
<br>
If the cpu_allocation_ratio is 1.0 then yes, this is correct. However,<br>
if it's any greater (and remember, the default is 16.0) then the gap is<br>
much smaller, though still broken.<br>
<br>
> With current master code, it’s possible to create only 4 instances<br>
> where now, by reporting both VCPU and PCPU, it will allow user to<br>
> create total of 8 instances which is adding another level of problem<br>
> along with the existing known issue. Is this acceptable?  because<br>
> this is decorating the problems.<br>
<br>
I think is acceptable, yes. As we've said, this is broken behavior and<br>
things are just slightly more broken here, though not horribly so. As<br>
it stands, if you don't isolate pinned instances from non-pinned<br>
instances, you don't get any of the guarantees pinning is supposed to<br>
provide. Using the above example, if you booted two pinned and two<br>
unpinned instances on the same host, the unpinned instances would float<br>
over the pinned instances' cores [*] and impact their performance. If<br>
performance is an issue, host aggregrates will have been used.<br>
<br>
[*] They'll actually float over the entire range of host cores since<br>
instnace without a NUMA topology don't respect the 'vcpu_pin_set'<br>
value.<br>
<br>
> If not acceptable, then we can report  only PCPU in this case which<br>
> will solve two problems:-<br>
> The existing known issue on current master (allowing both pinned and<br>
> non-pinned instances) on the compute host meant for pinning.<br>
> Above issue of allowing 8 instances to be created on the host.<br>
> But there is one problem in taking this decision, if no instances are<br>
> running on the compute node in case only ``vcpu_pinned_set`` is set,<br>
> how do you find out this compute node is configured to create pinned<br>
> or non-pinned instances? If instances are running, based on the Host<br>
> numa_topology.pinned_cpus, it’s possible to detect that. <br>
<br>
As noted previously, this is too complex and too error prone. Let's<br>
just suffer the potential additional impact on performance for those<br>
who haven't correctly configured their deployment, knowing that as soon<br>
as they get to U, where we can require the 'cpu_dedicated_set' and<br>
'cpu_shared_set' options if you want to use pinned instances, things<br>
will be fixed.<br>
<br>
Stephen<br>
<br>
</div>
</span></font></div>
Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying
 promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.
</div>

</blockquote></div></div>