On Tuesday, September 10, 2002, at 02:05 PM, Bernie Zenis wrote: I see that real SMT processors are finally being built which makes me happy. I just didn't know if Darwin had its foot in any of it. I'm thinking that for an SMT processor to become a real possibility for replacing (S)MP designs that the "thread" in SMT would have to refer to a full fledged process (eg, own address space, etc.). Would it be easier to port Darwin to a SMT processor in which its "threads" were light weight or full fledged? Or both equally well? The best ones are the ones that look like full-fledged second processors (full register set, including address space registers, etc...) even though they are just two sets of registers for a shared set of execution units. That's because, in the common case, the second thread that could benefit from getting started early (or that would benefit the current thread by not preempting it) runs in a different address space. In Mac OS X/Darwin, a common example is the IOKit workloop threads that run much of the code previously run in interrupt context. Being able to schedule these so that they interleave with the current thread, rather than preempting it (or waiting for it), is a big win (latency-wise). Normally, the stumbling point in doing this on true SMP machines is the overhead of kicking the other processor to make sure the top N (two, in our case) threads (priority-wise) are running at any given time. SMT processors can potentially reduce this overhead significantly (no need for bus transactions). The higher CPU clock rates go, the more "starved for real work" the execution units become. We have just crossed the threshold where things like wildly speculative execution are not filling those voids and tend to be counter-productive (cache-thrash-wise). If you are going to thrash the cache a bit, it would be better to know that it is being done on behalf of code that really *needs* to run. And if you happen to have two threads that are running in the same cache working set, it should really fly. That's because it is still quite hard to arrange for all the execution units to be busy with a single cache-resident thread of execution. These are the reasons why you are seeing a resurgence in the SMT notion. I, personally, can't wait to play with them to see if the implementation lives up to the theory. --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.