Re: Darwin & SMT?
Re: Darwin & SMT?
- Subject: Re: Darwin & SMT?
- From: Bernie Zenis <email@hidden>
- Date: Wed, 11 Sep 2002 11:17:59 -0400
On Wednesday, September 11, 2002, at 10:05 AM, Jim Magee wrote:
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.
As far as I am aware, there has been no work done on the possibility of
removing speculative instruction execution, out of order instruction
execution, nor branch prediction in SMT processors. Some/All of those
capabilities are complex and expensive. Removing them would create an
easier to design & test processor with a small die. However, you'd need
a SMT processor with enough thread contexts to keep the execution units
busy. And adding more thread contexts would increase the design
complexity and cost. It is a trade off and, not being a processor
designer myself, I don't know which would be better. I also don't know
if a typical Mac OS X/Darwin system has enough "busy" threads to keep a
high context count SMT processor filled with work.
Then there are the times when a single thread becomes dominant (and my
CPU Monitor graph fills). You might want speculative instruction
execution, out of order instruction execution, and branch prediction
back in that case. However, are there really that many tasks that have
to be run as a single thread? Can a majority (to darn near all) be split
up? But will any of those tasks, split into multiple threads, still have
the same characteristics as a single thread? On the plus side, Apple has
seen the value of multiple processors for a while now. Developers are
starting to see that breaking up tasks can have a real effect.
Last I heard, the SMT simulator is still Alpha only. Anyone been working
on a PowerPC version?
Thanks,
Bernie
_______________________________________________
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.