On Mon, 2008-07-14 at 18:12 -0400, [EMAIL PROTECTED] wrote:
> // Not just inexpensive, but also better aligned with how
> // they use compute resources (virtual vs. physical threads)
> // and memory resources.
>
> Hrm. I know about the memory/cache issues, but it sounds
> like there's more on the CPU side I don't know much about.
> Is there more here beyond the memory question and
> prediction/pipelining?
With, what is called CMT, we now have the following hierarchy
of compute resources:
-> physical CPU
-> cores
-> virtual threads
and the following set (I can't quite call it a hierarchy) of memory
resources:
physical RAM attached to a particular CPU's memory controller
L3/L2 cache
L1 cache
These two set of resources can be "attached" to each other in a number
of different ways (e.g. L1 could be the only per-core cache or L2
could also be per-core, etc.) and the job of a scheduler is to figure
out the best mapping of tasks to compute resources based on
alignment constraints. Paul had a nice post on these constraints
earlier. Here's an old post from Ingo outlining what is NOT free
with HyperThreading:
http://lwn.net/Articles/8553/
> // Speaking of which -- is SPARC port of Plan9 still alive?
>
> Not really. There's a partially-working sparc64 port out there
> which ran on the Ultra 1 (I think), but it's neither been kept up
> to date nor made to run on anything beyond that. A few folks
> (including myself) have poked at it a bit with varying results,
> none of which were particularly good.
>
> Something on Batoka would provide better motivation than my
> old Ultra 5, though!
I don't think I can help much with that, but if I ever see a
homeless Batoka in the hallway it'll be FedExed to you in
no time ;-)
Thanks,
Roman.
