Hmmm. Then if the scheduler is unaware of SMT, then even on a single-processor box SMT may degrade performance due to memory cache issues -- when two unrelated threads are executed in parallel, the effective size of the L1 and L2 caches is halved. With today's processor vs. DRAM speed difference, this may be significant. So even large caches, such as Xeon's, may be better used without SMT for certain workloads (namely, CPU-intensive computation with large work sets).
It would be neat if the scheduler knew it's better to run my Apache processes on the first CPU and my MySQL processes on the second (assuming the loads are equal), thereby avoiding duplication of the shared memory pages. Does it? Eran Gilad Ben-Yossef wrote: > Something non obious to note about SMT (or "Hyperthreading" as the Intel > PR people like to call it to make us all think they invented it :-) - > > Unless you're carefull, you'll get *less* performance when running with > these 2 sets of 2 virtualized CPUs as opposed to simply running two. > > Here is why: > > Let's call the real CPUs A and B and the virtual ones 1 and 2 so we end > up with : A1 A2 B1 and B2. > > Now assume you have 1 proccess running on A1 and now another proccess > has become runnable. > > Now, what you *want* the schdulers to do is asign the proccess to B1 or > B2, but what very well might happen is that the schduler (if it is > unaware of SMT) will pick A2 to run the new proccess. Since A2 and A1 > are really the same CPU, you're going to end up running the two proccess > slightly faster then you would run them on a single CPU but less fast > then you would have run them on a true SMP double CPU. > > Now, AFAIK Linux does have some scheduler code to handle this right, I > just can't seem to remember if it's in 2.4.x or only in 2.5.x ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
