Is it possible to tell which cpus are hyperthreads of the same core

hyperthreadingsmpvirtualization

I have a server that is a quad-core i-7 with hyperthreading enabled. The kernel recognises this as 8 cpus, as it should. I want to create a couple virtual hosts running on this machine. virt-manager lets me select which cpus are used on which machine. I want to configure this so that I assign both cpus in a hyperthreaded pair to the same virtual machine. This way one machine under heavy load will not effect another virtual machine by sharing a single core due to the hyperthreading. But I do want hyperthreading available to each vm because I am running tasks that involve heavy parallelization.

So, how can I tell which cpus the kernel recognizes are a pair? I would suspect cpu 0 and cpu 1 make a pair, then cpu 2 and cpu 3, and so on, but I am not sure how to test/confirm.

Best Answer

This link describes how to match physical id, core id, and sibling count to identify which entries in /proc/cpuinfo are on the same core, but I can make no claims as to its accuracy. It also looks similar to this question.

Related Solutions

Sql-server – Current wisdom on SQL Server and Hyperthreading

In the SQLOS a scheduler is created for each logical processor that SQL Server sees. With hyperthreading enabled this equates to double the schedulers. One of the purposes for the SQLOS is to minimize and prevent context switching from occuring which is why only one scheduler is created for each logical processor. Once the SQLOS creates the schedulers, the total number of workers is divided amongst the schedulers. The SQLOS implements a form of cooperative scheduling in that the workers yield the scheduler as it requires unavailable resources, or reaches its execution quantum allowing other workers to execute on the scheduler. This keeps context switching to a minimum since the scheduler is doing the work and they are bound one for one.

Understanding that background, hyperthreading somewhat works opposite of how SQLOS is specifically designed to function. Specifically, parallelism can be problematic with hyperthreading and can result in high CXPACKET waits since SQLOS may try to run a query at DOP 8 on what is reality a DOP 4 system. If your CPU utilization is low, you might not notice, but the higher your CPU utilization goes the more problematic it could become. I recently had a discussion on twitter regarding this, and the consensus was "It Depends" as to whether or not it would help or hurt.

If you have a lot of signal waits on your server, but you have low CPU utilization, you may see benefit enabling hyperthreading which will double your internal schedulers and spread the workers out more which means they won't wait to execute in the runnable queue as long. However if your workload utilized parallelism heavily you get heavy CXPACKET waits in sys.dm_os_wait_stats, you might look at disabling hyperthreading to see if it reduces your waits.

Linux – Disabling Hyperthreading Without BIOS Access

Newer Kernels provide a Simultaneous Multithreading (SMT) control.

You can check the state of SMT with;

cat /sys/devices/system/cpu/smt/active

Change the state with

echo off > /sys/devices/system/cpu/smt/control

Options are;

on
off
forceoff

We have tested this with Linux Kernel 4.4.0

Best Answer

Related Solutions

Sql-server – Current wisdom on SQL Server and Hyperthreading

Linux – Disabling Hyperthreading Without BIOS Access

Related Topic