Nehalem Hyperthreading w/ VI 3.5

[geekinabox]

Just listened to a VSphere Performance podcast w/ Scott Drummond where Scott indicated that you absolutely should enable Hyperthreading in Nehalem-based boxes runnign VSphere. Accoring to Scott a.) the vast improvements in Intel's implementation of HT/SMT, coupled w/ b.) optimizations in VSphere to leverage HT/SMT, make it's usage an absolute no-brainer.

Which begs the question: what about VI 3.5?

Like many large shops we're not going to upgrade to VSphere for a bit (prb another 6-9 months), but we are in the process of rolling out Nehalem-based hosts. Is HT for 3.5 still a no-brainer? If not, what considerations should I take into account in assessing whether or not to implement it.

Comments appreciated ... (Scott??)

[weinstein5]

Same theory applies - by enabling HT you are providing the vmkernel more locations to schedule virtual CPUs - this is true of vSphere and ESX 3.x -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[geekinabox]

Thanks for the reply.

I assumed as much, but just wanted to make sure that Vi 3.5 would not suffer since it does not have particular hyperthreading-related optimizations that were apparently made in vsphere

[weinstein5]

Actually vi-3 does - it has just has been enhanced in vsphere

Sent from my iPhone

On May 29, 2009, at 2:56 PM, "geekinabox" <communities-emailer@vmware.com

[drummonds · Accepted solution]

Good question. We know the answer to this in such detail that it merits a whitepaper. Expect that paper in the next four weeks. But let me give you the highlights while you're waiting.

Hyper-Threading (HT) from the hardware's perspective: Intel changed HT for the better. To the best of our knowledge, HT is now provides a universal benefit. Unlike previous versions of HT, where pathological workloads could result in HT slowing down performance, we think no such workload exists any more. The new HT seems to benefit consolidated workloads by 10-30% in most cases, as compared to a lack of HT.

Hyper-Threading from the user's perspective: Since we support Hyper-Threading in all versions of ESX, we'll see a baseline improvement thanks to Intel's changes. Even without adding specific optimizations for the new HT, ESX 3.5 (and before) will show commensurate gains. I'll have to refer you to Intel to put these to numbers, but on average I'd expect the new HT to provide 5-10% better performance than the old HT. And, again, there should be no cases where the new HT slows things down.

Hyper-Threading from the scheduler's perspective: Schedulers are forced to assume something about the relative value of Hyper-Threading. In doing so they use accounting that assigns value to to a dedicated physical core as compared to a logical core that is being shared with another thread. That value determines how much the scheduler will rely on the technology, which in turn will diminish or magnify the impact of the gain. In vSphere we've added a scheduler change that "trusts" HT more than before. This means that vSphere will see larger gains due to HT on Nehalem (Xeon 5500) than 3.5 or earlier will see on HT on Nehalem. Incidentally, we're going to backport this HT change into 3.5 at an unspecified, but not too distant date.

I know all you techno-junkies are queuing up more questions on this subject but I'll ask you to hold off until we finish the whitepaper. I'm doing a whitepaper a week for months to come. Stay tuned to my blog, Twitter, and VROOM!

Scott

More information on my communities blog and on Twitter:

http://communities.vmware.com/blogs/drummonds

[geekinabox]

Scott --

Belated thanks for the reply. Your info was very helpful and I'm keeping one eye on VROOM! for this and other helpful information.

Here's some other info I I hope you (or other resources) can help address--

I'd be curious (perhaps in your VROOM post?) to deepen my understand of how the hypervisor sees this hyperthreading and how this impacts resource management. In particular, I'd like to know how hyperthreading plays into how I do resource reservations on VMs and RPs. I.e., assuming a host has Nehalems that run at 2200MhZ. Theoretically a dual socket, quad core, non-hyperthreaded host would therefore allow resource reservations to be placed for up to ~17600 MhZ (2200 * 2 * 4).

How would this work with hypterthreading turned on? Does this double the MhZ I can guarantee via reservations? Obviously hyperthreading does not 'truly' double the performance of the CPU on the box, but it does improve it. So, ultimately, how does this improvement translate into the MhZ-measured finite CPU resource pool out of which I allocate/guarantee resources?

Thanks for your contributions .

Looking forward to

[drummonds]

This is a good question. I don't think that any one person has a precise answer to this today. I'll see if I can meet with the minds behind resource management and HT scheduling when I return to the states. Perhaps I can get a VROOM article posted on the subject.

Scott

More information on my communities blog and on Twitter:

http://communities.vmware.com/blogs/drummonds

[duffer-69]

Do you have any updates on this topic regarding the performance with Nehalem Hyperthreading w/ VI 3.5