Re: Darwin & SMT?
Re: Darwin & SMT?
- Subject: Re: Darwin & SMT?
- From: Jim Magee <email@hidden>
- Date: Wed, 11 Sep 2002 10:05:58 -0400
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.