16 messages in org.freebsd.freebsd-archRe: Larry McVoy's slides on cache coh...| From | Sent On | Attachments |
|---|---|---|
| Terry Lambert | Jun 26, 2002 11:29 pm | |
| Greg 'groggy' Lehey | Jun 27, 2002 12:11 am | |
| Bill Huey | Jun 27, 2002 2:11 am | |
| Julian Elischer | Jun 27, 2002 10:48 am | |
| Gary Thorpe | Jun 27, 2002 11:18 am | |
| Matthew Dillon | Jun 27, 2002 12:00 pm | |
| Terry Lambert | Jun 27, 2002 1:20 pm | |
| Jonathan Lemon | Jun 27, 2002 1:25 pm | |
| Terry Lambert | Jun 27, 2002 2:27 pm | |
| Brooks Davis | Jun 27, 2002 3:25 pm | |
| Peter Wemm | Jun 27, 2002 4:01 pm | |
| ne...@xyz.com | Jun 27, 2002 5:34 pm | |
| Gary Thorpe | Jun 27, 2002 9:41 pm | |
| Matthew Dillon | Jun 27, 2002 9:53 pm | |
| Gary Thorpe | Jun 27, 2002 10:01 pm | |
| Brooks Davis | Jun 28, 2002 10:18 am |
| Subject: | Re: Larry McVoy's slides on cache coherent clusters | |
|---|---|---|
| From: | Terry Lambert (tlam...@mindspring.com) | |
| Date: | Jun 27, 2002 1:20:11 pm | |
| List: | org.freebsd.freebsd-arch | |
Julian Elischer wrote:
Not "overly impressed" is not quite accurate..
"not sure that it was relevant to us" is more to the point
He was against making the system scale to N processors where N is a large number, stating that if corrupted the system too much to have such fine grained locking, and that such large-scale MP situations should be achieved with clusters of "Small-N" machines, connected together by higher level constructs.
I did take some mental notes from the meeting. e.g. "make sure we don't make our kernel TOO fine grained.
You should read the slides at http://www.bitmover.com/cc-pitch/ ; it should take you all of four minutes, if you skip the loading of the picture in slide 29, or if you have a fast link.
He actually wants systems to be able to scale to N processors, but he believes that the way this will happen is by clustered instances of the OS, rather than running a single OS image on an indefinite number of processors.
It makes sense, since his belief appears to be that at some point, a large N means that the system will be NUMA.
He also makes the point that 99% of all systems are in fact not SMP (he has statistics to back this supposition), and thus there needs to be a weighting of effort relative to the user base for the resulting code. It's very intersting reading.
You could actually argue that NUMA bears the same relationship to shared memory multiprocessors as shared memory multiprocessors bear to SMT processors. In all likelihood, you will have machines that are technically uniprocessor that have hyperthreading enabled in far more installations than you will ever have true SMP via multiple discrete CPUs.
My personal target rests above NUMA, where there are relatively glacially slow communications channels, compared to CPU speed; this is basically the environment in which, for example, you have literally millions of processors operating from incomplete information with potentially lossy communications channels.
-- Terry
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message