File this under a tip that we recently sent to a reader, and one we use all the time. If you need to turn SMT or on Intel CPUs with the feature, Hyper-Threading then a common way to do so is to go into the BIOS and flip the SMT or Hyper-Threading enable/ disable toggle. While that is often great for those times when a reboot and a BIOS trip are feasible, it is not the right answer for every situation. Instead, we have a simple script to help you out so you can disable the extra SMT threads quickly.
A Guide to Quickly Enable and Disable SMT and Hyper-Threading on Ubuntu and Debian
One easy way if you do not want to script it is to use the good old smt control. You can use the following to see the state:
cat /sys/devices/system/cpu/smt/activeTo turn SMT on, use:
echo on | sudo tee /sys/devices/system/cpu/smt/controlTo turn SMT off, use:
echo off | sudo tee /sys/devices/system/cpu/smt/controlTurning on the SMT threads usually takes a few seconds, so you may need to wait a bit for the command to run. Also, you will need to use sudo to run this command since it is making a fairly substantial system change.
Final Words
Different applications can benefit from SMT. While for many HPC workloads, SMT off is what folks want to use. For other applications, SMT on can add a very notable bump. In virtualized workloads, oftentimes SMT on means two vCPUs that can be provisioned and so in systems that support it, it can help a lot.
In the lab, we usually use a script to do this, but the faster option for a lot of folks is to just use the above commands and turn SMT on and off quickly. For some folks, the BIOS option is a better option, but this is a quick and dirty way to make it work.
“Turning on the SMT threads usually takes a few seconds”
Is there something intrinsically expensive about doing it, with the process always taking some seconds to complete; or is it a matter of needing to migrate everything running on the SMT ‘cores’ that are going to disappear onto real cores that will not; with completion time potentially ranging from almost nothing(in the case of extremely lightly loaded systems or ones where processes have already been pinned to physical cores in advance) to fairly significant(in really high load cases where tons of migration needs to happen)?
I wonder if there is any difference compared to switching it off in BIOS? There might be some CPU resources that are statically partitioned, especially on older CPUs. So turning SMT off is not the same as having it on but not scheduling anything on the adjacent threads.
@fuzzyfuzzyfungus
Moving user processes is not a problem, but SMT threads can also host kernel processes which do have higher latencies of migration since they rarely get migrated in the first place.
Especially if those kernel threads are currently processing uninterruptible tasks and/or handling physical IOs. The interrupt controllers also have to be re-programmed to point vectors to the new CPUs, and on very busy systems it’s not done quickly.
@Nikolay Mihaylov
Yes, runtime SMT/HT control should only be the last resort. It’s better to use the kernel command-line “nosmt” to disable it at the CPU initialization time on boot. The best method is via firmware (BIOS Setup).
The article should also mention that re-enabling SMT after it’s been disabled at runtime/kernel parameter is not recommended by the kernel developers. In fact disabling at runtime should be done with “forceoff” instead of “off” to block future “on” attempts.
More interestingly is that SMT can be enabled / disabled on a per core basis using hotplugging, which ought to avoid the problem with re-enabling SMT: https://access.redhat.com/solutions/rhel-smt
This method offlines the SMT threads which works. We use it. On big systems it can take minutes though, but that’s usually faster than booting. It’s also useful if you want to run a live setup that you’re wanting to test b2b in scripts.
@Rob
Yes, it can be done this way as well, but it’s still not recommended, and should be considered a temporary solution until properly doing it in firmware.
Even on the site you linked it’s warned against: “Red Hat strongly recommends against enabling or disabling SMT at runtime.”.
There are good reasons for that. Most software isn’t routinely tested in a variable CPU count environment and can break in unusual ways when you yank CPUs from the system. Not every system is properly configured for hot-adding CPUs, be it real or SMT, either since there are actions required to restore optimal performance.