Slashdot Mirror
Hyper-Threading Speeds Linux
developerWorks writes "The Intel Xeon processor introduces a new technology called Hyper-Threading (HT) that makes a single processor behave like two logical processors. The technology allows the processor to execute multiple threads simultaneously, which can yield significant performance improvement. But, exactly how much improvement can you expect to see? This article gives the results the investigation into the effects of Hyper-Threading (HT) on the Linux SMP kernel. It compares the performance of a Linux SMP kernel that was aware of Hyper-Threading to one that was not." Ah, the joys of high performance.
Here is the associated press release from Intel about the HT in 3 Ghz P4's. I have seen screenshots of Windows task manager showing (2) CPU performance graphs.
I believe it emulates the dual CPUs, so the OS should see it as 2 chips. That's why XP Home wouldn't take advantage of it, but XP Pro/2K would.
Yeah
SMP support has existed since NT 4.
If you use NT 4 MP edition, 2k Pro or XP pro, HT just works if you have the hardware.
Linux had to change to accomodate it, as it bypasses the original system BIOS with it's own code.
So what you meant to say was "once again Linux plays catchup to MicroSoft, but only about a year or so later this time, and not 5-10."
I don't need no instructions to know how to rock!!!!
On moft platforms, CL.exe goes file per file, and outputs. It's a linear opertation. So HT for compiling makes no difference.
However, the NT DDK has a cool feature that allows you to spawn as many instances of CL as there are processors. Which you guessed it, is only of any use if you are compiling tens/hundreds of files.
Sorry, I do not really know of compiler internals for *NIX. Maybe someone can back me up? or clear it up?
Hyperthread support vs not.
Standard API calls (w/ hyper thread) Increase (a bad thing (tm)) of latency of calls by 1-6%.
STD workload (w/ hyper thread) Increase in throughput an average of 5-10%. Disk writes decreased throughput by 30%.
Client network perf: "Chat room" test, increase of throughput 22-28%.
Server network perf: File serving, increase of 9-31%.
Kernal 2.5.24 roughly doubles the above benefits.
Looks like no real downfalls... (How often are you running a single thread? Me either.)
SMP already can gain benefit from hyperthreading. However, an OS really needs special support to A) get the most out of hyperthreading and B) avoid worst-case scenarios, especially when you have both multiple physical CPUs and multiple logical CPUs per physical CPU.
For instance, if you have two processes running, you want to put them on different physical CPUs, and if you have a choice, grouping threads with the same memory image on a single processor improves cache usage.
Without this, hyperthreading may
The downside is that for code that isn't SMP/HT-aware, performance can actually degrade. Tom's Hardware ran tests of hyperthreading on the 3.06GHz P-4, and in almost every case, it performed better with hyperthreading disabled.
Breakfast served all day!
processes can start being migrated around to CPU's that do not really exist and appear to have no load, yet the physical CPU may be 100% loaded in reality
The article indicates that they're fixing this in the 2.5 branch. Lots of additional patches to the scheduler to let it comprehend the difference between physical and logical processors and do the Right Thing with them.
Oh, and if you're running a 2 CPU box with only a couple (as in two) large jobs then no, you won't see a performance gain. You already have 1 CPU/process and HT would just be additional overhead.
Holy intellectual dishonesty, Batman!
NT and Windows 2000 do not support HT and never will. NT will not becuase it's been end-of-lifed, and Windows 2000 will not because of Microsft policy. On a 2-CPU system with HyperThreading, NT and Windows 2000 will think they have real 4 CPUs (unsurprisingly, this is what a pre-HT version of Linux will see as well). HT support means the OS knows that it has, in this example, 2 real CPUS and 2 fakes, and the scheduler will weight the real CPUs accordingly.
XPPro SP1 is the first, and only shipping version of Windows to support HT.
While Win2K will see a hyper-threaded CPU as 2 physical CPUs, WinXP is smart enough to see it as a CPU and a Virtual CPU. At the last Intel conference I attended they made sure to emphasize that while XP Home doesn't support 2 phyisical prosessors it will properly recognize a hyper-threaded CPU and allocate resources accordingly. Do you think Intel would enable the technology in the P4 3Ghz(a desktop CPU) without making sure Microsoft supported it in their desktop operating systems?
Nope, win2k only shows 2, well at least for pro. It also binds to the first physical cpu and it hyperthreaded child. For this reason you have to turn off hyperthreading if you are going to install win2k pro on a 2 physical cpu workstation, I should know I have a system reimaging right now because it came from the factory with hyperthreading enabled and so only 1 physical cpu was being used.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
There's a reason some sites have multiple racks of dedicated web servers, and any technology that lets them serve more users in less physical space is going to be a win if the cost isn't prohibitive.
One of the major impediments to increasing CPU performance has been increasing memory latency. Memory latency has grown worse as CPUs have gotten faster. Accessing RAM will now cause a >150 cycle latency, during which the processor sits IDLE.
Cache only partly mitigates this problem. Some applications, such as databases and OLTP, are heavily dependent on repeatedly accessing non-cached RAM. There is no way to cache all the relevant data, since virtually all databases are larger than can fit in any present cache, no matter how large, and there is sometimes no way to predict which data will be accessed. ALL of these applications have CPUs that spend much of their time being IDLE, waiting for memory to be returned.
SMT (hyperthreading) allows the processor to perform useful work during these otherwise idle periods, by allowing the cpu to switch to a thread that is not blocked on memory access. The "idle bubbles" in the execution pipeline can therefore be "filled in" by useful work that advances the state of relevant programs.
SMT can cause a degredation in performance beceause it can lead to "cache thrashing." In an SMT-naive kernel, two unrelated threads could be scheduled for the same physical CPU. These unrelated threads will likely share very little code or data. The two threads will therefore "compete" for the single shared cache, with each thread's data being repeatedly displaced by the other's.
This difficulty can be substantially mitigated by making the kernel aware of "virtual processors," and by implementing scheduleing algorithms to minimize the impact. The performance of hyperthreading will likely improve as kernels are better able to exploit it.
Any SMP capable operating system supports HT. On the other hand license issues make combining true SMP and HT a pain on non server version of Windows.
You're totally missing that part of the beauty of HT is the transparency.
On the other hand you can write things SPECIFICALLY for HT to deal with things such as cache issues, but saying that windows doesn't support it at all is rather misleading and makes it seem like people wouldn't see any improvements at all.
Care to explain what these mean?
I'll explain to you what this means:
it means a piece of hardware raising an interupt will launch a driver's ISR, hardware wise, at that point, any other hardware raising an interupt at a lower IRQ level will not be serviced. BUT, any higher IRQLed hardware can take over of that 'thread' that is servicing the first interupt. There are *no* exceptions to this rule. In effect, your ISR is fully interuptible.
The thread dispatcher runs at DIRQL (D=Disptach), any IRQL higher than DIRQL is kind of beyond the concept of threads. But any thread running bellow DIRQL (ie, APC or normal threads) are fully pre-emtible. There is no thread that has *any* priority of not being pre-empted anywhere in the system.
All of the kernel is also re-entrant, which means from anywhere within the kernel, so long as you are in proper IRQL, you can call back the kernel.
At these altitudes, or depths, whichever you wish, there are many strange beasts that you've never heard of - or never had a reason to really use - that are being used to do synchronization. Namely spin locks. Moft came up with queued spin locks a few years ago, and that was a rather Good Thing (tm). It made spin locks so much better under SMP systems.
Now, to all the posts that say "all I need is an OS that doesn't suffer from SMP", all I have to say is why do you use SymmetricalMP in the first place??! Why not use assymetrical processing, and just queue all interupts on a single CPU? it'll sure as hell simplify everything, and reduce overloading the bus with those damn spin locks!
If you're going to claim that the Linux kernel is doing a good job of an SMP system, you have to show me it's actually performing better. Not just allowing more threads to run on more processors... everyone can do that.
Second thing is: don't flatter yourself by 'easy wins'. All I'm saying is that this is just *not* an win for linux. It's only a win for HT and multithreading... but hey, we all knew that Multithreading is a Good Thing(tm)... right?
From what I've read, XP Home allows the use of 2 virtual CPUs, just not two physical CPUs. So any HyperThreading procs would work just fine.
-- Your IP is showing