On Tue, 29 Oct 2002 15:12:41 -0500 Javier Guerra <listasJGG@eos.com.pe> wrote: > if you get those two things, your machine will look as a dual CPU to > the software, so you could just compile a SMP kernel .... and find it > slower than before > > why? > > because those two 'virtual CPU's on each real cpu aren't full > processors, > just two streams of instructions kept separate by the instruction > dispatcher and a clever hack of the existing register renaming units. > you don't have > more horsepower to apply to two streams You don't have *more* horsepower, you just *utilize* it more. > > so, what is it good for? > > the main bottleneck right now on the x86 architecture is getting such > an old instruction set work nice with a superscalar processor. since Nope. The "old instruction" set disappears in pretty early state in the pipeline(s). From that point on Intel CPUs are like everyone else's RISC CPU. > it's so dificult for the OOOD unit to find enough non-exclusive > instructions to fill the queues, it makes sense to pick instructions > from two separate execution threads. This is true indeed for all CPU architectures out there, which is not a surprise as it has nothing to do with CPU architecture, but rather with compilers architecture and the way people write programs. > and the catch? > > but the tradeoffs to be considered by the OS's scheduler are > absolutely different from having two real CPUs. the worst example is > having two real hyperthreading CPUs: P0 and P1, each having two > 'virtual cpus': vP00 and vP01 on P0 and vP10, vP11 on P1. > > then; if the scheduler sees those as just 4 cpus, and has (for this > example) two ready processes. it might try to run them on vP00 and > vP01, leaving vP10 and vP11 idle. > > this would be fine if those 4 cpus were really independent, but here > vP00 and vP01 are 'siblings' and using one makes the other slower; > creating the imbalance and seriously degrading performance. sometimes > more than 40% > > so it's just crap? > > no, a fully HT-aware scheduler could make good use for it, achieving > performance gains of 10%-15%, and almost never getting it worse than > disabling HT. > > Ingo Molnar wrote a patch for the O(1) scheduler kernel, getting it to > deliver steady performances, instead of the wild fluctuations seen > with the stock kernel. read about it here > http://kerneltrap.org/node.php?id=406 Yep. Besides HT-aware thread scheduler, there's a need for HT-aware load balancing of interrupts, too, so you don't end up serving all the interrupts on one physical CPU. ~velco -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
