<div dir="ltr">Thanks all for the reply, I guess it will be better to config those preference using flavor/image according to different hardware then.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 1:21 AM, Mooney, Sean K <span dir="ltr"><<a href="mailto:sean.k.mooney@intel.com" target="_blank">sean.k.mooney@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> -----Original Message-----<br>
> From: Jay Pipes [mailto:<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>]<br>
> Sent: Tuesday, June 20, 2017 5:59 PM<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.<wbr>org</a><br>
> Subject: Re: [openstack-dev] [openstack-dev[[nova] Simple question<br>
> about sorting CPU topologies<br>
><br>
> On 06/20/2017 12:53 PM, Chris Friesen wrote:<br>
> > On 06/20/2017 06:29 AM, Jay Pipes wrote:<br>
> >> On 06/19/2017 10:45 PM, Zhenyu Zheng wrote:<br>
> >>> Sorry, The mail sent accidentally by mis-typing ...<br>
> >>><br>
> >>> My question is, what is the benefit of the above preference?<br>
> >><br>
> >> Hi Kevin!<br>
> >><br>
> >> I believe the benefit is so that the compute node prefers CPU<br>
> >> topologies that do not have hardware threads over CPU topologies<br>
> that<br>
> >> do include hardware threads.<br>
</span>[Mooney, Sean K] if you have not expressed that you want the require or isolate policy<br>
Then you really cant infer which is better as for some workloads preferring hyperthread<br>
Siblings will improve performance( 2 threads sharing data via l2 cache) and other it will reduce it<br>
(2 thread that do not share data)<br>
<span class="">> >><br>
> >> I'm not sure exactly of the reason for this preference, but perhaps<br>
> >> it is due to assumptions that on some hardware, threads will compete<br>
> >> for the same cache resources as other siblings on a core whereas<br>
> >> cores may have their own caches (again, on some specific hardware).<br>
> ><br>
> > Isn't the definition of hardware threads basically the fact that the<br>
> > sibling threads share the resources of a single core?<br>
> ><br>
> > Are there architectures that OpenStack runs on where hardware threads<br>
> > don't compete for cache/TLB/execution units?  (And if there are, then<br>
> > why are they called threads and not cores?)<br>
</span>[Mooney, Sean K] well on x86 when you turn on hypter threading your L1 data and instruction cache is<br>
Partitioned in 2 with each half allocated to a thread sibling. The l2 cache which is also per core is shared<br>
Between the 2 thread siblings so on intels x86 implementation the thread do not compete for l1 cache but do share l2<br>
That could easibly change though in new generations.<br>
<br>
Pre xen architure I believe amd shared the floating point units between each smt thread but had separate integer execution units that<br>
Were not shared. That meant for integer heavy workloads there smt implementation approached 2X performance limited by the<br>
Shared load and store units and reduced to 0 scaling if both Treads tried to access the floating point execution unit concurrently.<br>
<br>
So its not quite as clean cut as saying the thread  do or don’t share resources<br>
Each vendor addresses this differently even with in x86 you are not required to have the partitioning<br>
described above for cache as intel did or for the execution units. On other architectures im sure they have<br>
come up with equally inventive ways to make this an interesting shade of grey when describing the difference<br>
between a hardware thread a full core.<br>
<span class=""><br>
><br>
> I've learned over the years not to make any assumptions about hardware.<br>
><br>
> Thus my "not sure exactly" bet-hedging ;)<br>
</span>[Mooney, Sean K] yep hardware is weird and will always find ways to break your assumptions :)<br>
><br>
> Best,<br>
> -jay<br>
><br>
> ______________________________<wbr>______________________________<wbr>___________<br>
<div class="HOEnZb"><div class="h5">> ___<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">request@lists.openstack.org?<wbr>subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>