On Thu, May 15, 2008 at 04:57:03PM -0400, Justin wrote: > Isn't that the rub point in HT processor. A process running in HT > virtual processor can lock up a specific chunk of the real processor up > that would not normally be locked. So the process running in the Real > processor gets blocked and put to sleep till the process running in HT > is cleared out. There is no "real" or "virtual" processor, HT is symmetric. Both look like real CPU's but internally they share certain resources. The advantage is that if a program gets a cache miss it will stall for dozens of cycles waiting for memory. On a real multicore CPU that's wasted time, on an HT CPU there is another thread which can (hopefully) keep running and use the resources the other isn't using. For programs like GCC which are waiting for memory 50% of the time of so, HT can provide a measurable increase in performace. For computationally expensive programs it may be worse. > As time has progress the kernel schedulers i imagine have improved to > better understand that this virtual processor locks parts of the real > processor up so it needs to schedule things a little better so it don't > keep dumping things into the HT processor that it will need a second > latter for another process it queried for the real processor. The thing is that HT processors share an L1 cache so switching between two HT processors on the same die is much less expensive than switching to another core. But if you have only two runnning processes it better to split them across two cores. Schedulars know this now, they didn't at first. Have a nice day, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
Attachment:
signature.asc
Description: Digital signature
