Hyper-threading doesn't count?

[scottgus1]

In this thread: viewtopic.php?f=6&t=54182 mpack asked:

"what is the host CPU? How many real cores does it have (hint: hyper threading doesn't count)."

I did some reading on hyper-threading and saw that the performance improvements depend on the kind of programs running on the processor:

Wikipedia, http://en.wikipedia.org/wiki/Hyper_threading
"Hyper-threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources."
"when running two programs that require full attention of the processor it can actually seem like one or both of the programs slows down slightly when Hyper-Threading Technology is turned on"

Is the reason why hyper-threading doesn't count that more than one guest running at the same time executes similar commands on the processor and therefore while one guest's command is executing, another guest's command has to wait because the processor can only execute one of those commands at a time?
Or is it something else?

[mpack]

Hyperthreading is like a worker with two heads but still only one pair of hands. If you happen to have two tasks that only require one hand each (and don't care which) then the two can run in parallel. However with any real-world complex task there is likely to be a conflict over resources, and one of the tasks will stall. Hyperthreading is a way of giving an illusion of multi-core with a few of the benefits, e.g. fast context switching. However if you want a host and a VM to run independantly at almost full speed then truly independant cores is the only way to go. Of course even that is an illusion: ultimately those cores are still accessing shared resources (data bus, RAM, disks), so they can't run wholly without regard for each other, but it's much more likely that'll you'll get good performance from true multi-core.

[scottgus1]

Gotcha. Makes good sense. Thanks, Mpack!

[antevans]

There's more to it than that. Hyperthreading works only when the OS has enough information about the physical architecture to distinguish which virtual core is on which physical core. The OS must spread busy threads across different physical processors, not different logical processors. If it doesn't have that information, it will schedule at random. In a hyperthreaded system, in that scenario it will get it wrong half the time, creating random CPU contention even when there are free cores.

Of course, the OS does know which virtual core is on which physical core, because the CPU tells it. Or does it? Here is coreinfo output from the same hyperthreaded Core i5, as the host, and as the guest.

Host

• Logical to Physical Processor Map:
  **-- Physical Processor 0 (Hyperthreaded)
  --** Physical Processor 1 (Hyperthreaded)

Guest

• Logical to Physical Processor Map:
  *--- Physical Processor 0
  -*-- Physical Processor 1
  --*- Physical Processor 2
  ---* Physical Processor 3

Hypothesis: a VB guest is unable to schedule rationally across physical cores, and its performance will be compromised as a result.

The decisive question is how guest threads actually get scheduled. If they're done natively, on the metal, by the guest, then scheduling will be random, on this limited evidence, and performance will suffer. If, on the other hand, the host is scheduling threads on the guest's behalf, without the guest knowing, then you have a decent chance that scheduling will be done optimally across physical cores.

The fact that you can assign more cores to the guest than there are virtual cores in the host is a pretty strong clue that it's the host doing the scheduling.

The empirical test of this is to run, repeatedly, a bunch of two-threaded benchmarks in the guest with four physical cores, and with four virtual cores. Two ways to do this: apply an affinity mask to the host VB process to force it across different physical cores to simulate two physical cores; or run the host without hyperthreading. If hyperthreading works properly in the guest you'd expect there to be no significant difference in performance between four virtual and four physical guest cores, when the host is idle.

I think you get the equivalent info under Unix using /proc/cpuinfo. I don't have a HT Unix host to try it on.

Anyone?

[martyscholes]

I have wondered similar things about multi-socket machines. The server I use has four sockets, each dual-core, but the memory is allocated per-socket. That means if a thread is scheduled on one CPU but the memory needed is on the bank of another, it must be shipped over via hypertransport. Does the guest or the host account for these nuances when scheduling?

[mpack]

I don't keep up with PC motherboards any more (my work is in embedded CPUs), but I'd imagine that the OS shouldn't care about memory access. It's possible to design a memory access / cache management unit which avoids bus contention unless the memaccess is in the same n-byte page. I assume modern PCs are at least as sophisticated. I imagine the CPUs which can be put into these multi-socket boards will be explicitly designed to link up and share mem arbitration duties.