Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a system running a financial trading application at a remote facility. I do not have access to the ILO/DRAC, but need to disable hyperthreading. The system runs Intel Nehalem 3.33GHz X5680 hex-core CPUs. I can reboot, but want to make sure that the system does not enable hyperthreading due to performance problems. Is there a clean way to do this from within Linux?

Edit: The noht directive added to the kernel boot command line did not work. Same for RHEL.


share|improve this question

5 Answers 5

Yes. Append the noht parameter to the kernel on boot.

From :

The `noht' Argument

This will disable hyper-threading on intel processors that have this feature. 

If using lilo edit you /etc/lilo.conf (and run lilo afterwards) or if using grub then edit your /boot/grub/menu.lst .

share|improve this answer
Is this functionally equivalent to disabling HT in the BIOS? – ewwhite Feb 15 '11 at 18:26
I don't know that for sure, but yes, I would expect noht to be equivalent to disabling it on the BIOS. – rems Feb 15 '11 at 18:52
This is a Gentoo system. I tried the noht entry in the grub kernel command line. The system did not honor the noht command. Same for RHEL. See: – ewwhite Feb 15 '11 at 19:41
up vote 1 down vote accepted

I had to wait until I could get into the ILO/Drac. The kernel boot parameters do not work on current Linux distributions.

share|improve this answer
can you describe how you actually did that? – edward torvalds Sep 13 at 12:39
@edwardtorvalds It depends on the server. – ewwhite Sep 13 at 12:53
what about the servers that run on Intel processor and latest kernel? – edward torvalds Sep 13 at 13:27
@edwardtorvalds Please ask a new question. – ewwhite Sep 13 at 13:28

In the libsmbios-bin package (Debian, Ubuntu, etc), you have the binaries isCmosTokenActive and activateCmosToken. Together with the token list, you can then try something like this:

# isCmosTokenActive 0x00d1 # CPU_Hyperthreading_Enable
[...] Type 0x00d1  Location 0x46 AND(fe) OR(0)  BITFIELD: 1
# isCmosTokenActive 0x00d2 # CPU_Hyperthreading_Disable
[....] Type 0x00d2  Location 0x46 AND(fe) OR(1)  BITFIELD: 0

Then activate the CPU_Hyperthreading_Disable token:

# activateCmosToken 0x00d2 # CPU_Hyperthreading_Disable
[...] Type 0x00d2  Location 0x46 AND(fe) OR(1)  BITFIELD: 1


# isCmosTokenActive 0x00d1 # CPU_Hyperthreading_Enable
[...] Type 0x00d1  Location 0x46 AND(fe) OR(0)  BITFIELD: 0
# isCmosTokenActive 0x00d2 # CPU_Hyperthreading_Disable
[...] Type 0x00d2  Location 0x46 AND(fe) OR(1)  BITFIELD: 1

Now, the big question is whether or not you simply need a reboot for this to take effect, or if a full power cycle is required. Try it out and see how it goes!

share|improve this answer

You can do this at runtime if you want to. I found a nice solution described here:

Step 1: Identify the linux CPUs you want to switch off:

cat /proc/cpuinfo

Look for the CPUs that have the same "core id", you want to switch off one of each pair.

Step 2: Switch off the hyperthreading CPUs (in my case the last four of the total 8 "CPUs" seen by Linux)

echo 0 > /sys/devices/system/cpu/cpu4/online
echo 0 > /sys/devices/system/cpu/cpu5/online
echo 0 > /sys/devices/system/cpu/cpu6/online
echo 0 > /sys/devices/system/cpu/cpu7/online

You could setup yourself a script that you run just after system start.

Best regards, Alexander.

share|improve this answer
It works almost as I expected. virtual cores are disabled, now when I execute one cpu-consuming thread it loads physical core by 100%. But using sysbench --num-threads=1 --test=cpu run with different num-threads and HT turned on and off says that disabling HT decreases perfomrance when there are many threads, and even if there's just one thread there's no benefit from turning HT off. So I suggest to leave it as it is: it's optimal. – Sergey P. aka azure Dec 31 '14 at 13:43

A script to disable hyperthreading in the machine startup...

To disable hyperthreading I include a script on machine /etc/rc.local. It is not exaclty clean, but is easy to install, independent of cpu architecture and should work on any modern linux distribution.

nano /etc/rc.local

    # place this near the end before the "exit 0"

    for CPU in /sys/devices/system/cpu/cpu[0-9]*; do
        CPUID=$(basename $CPU)
        echo "CPU: $CPUID";
        if test -e $CPU/online; then
                echo "1" > $CPU/online; 
        COREID="$(cat $CPU/topology/core_id)";
        eval "COREENABLE=\"\${core${COREID}enable}\"";
        if ${COREENABLE:-true}; then        
                echo "${CPU} core=${CORE} -> enable"
                eval "core${COREID}enable='false'";
                echo "$CPU core=${CORE} -> disable"; 
                echo "0" > "$CPU/online"; 

How this works?

Linux kernel information and controls can be accessed as files in /sys directory on modern linux distributions. For example:

/sys/devices/system/cpu/cpu3 contains the kernel information and controls for logical cpu 3.

cat /sys/devices/system/cpu/cpu3/topology/core_id will show the core number this logical cpu belongs to.

echo "0" > /sys/devices/system/cpu/cpu3/online allows to disable logical cpu 3.

Why it works?

I do not know exactly why... but the system become more responsive with hyperthreading off (on my i5 notebook and massive Xeon servers with 60+ cores). I guess that has to do with per-cpu caches, per-cpu memory allocation, cpu scheduler allocation and process priorities complex iterations. I think the benefits of hyperthreading is outweight by the complexity of making cpu schedulers that know how to use it.

For me, the problem with hyperthreading is: If I start as many cpu-intensive threads as I have logical cores, I will have fast context switches for the cpu intensive tasks, but expensive ones for the background tasks since the hyperthreading totally consumed by the cpu intensive tasks. On the other hand, if I start as many cpu-intensive threads as I have physical cores I will have no context switches to those tasks and fast context switches for the background tasks. Seems good, but the background tasks will found free logical processors and will run almost imediatedly. It is like they are realtime performace (nice -20).

In the first scenario the hyperthreading is uselles, the background tasks will use expensive context switches because I maxed out hyperthreading with the normal processing. The second is unaceptable because up to 50% of my cpu power gets prioritized to the background tasks.

The "cpu-intensive" tasks I am talking about are artificial intelligence data mining and authorization servers (my work). Blender rendering in cheap computers and clusters (to sketch my future house).

Also, this is guesswork.

I have the impression that is better, but it may not.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.