Hi,
>> Nor will you find any match with 4 or 8 CPU systems, except in very rare
>> cases. Yet changes go into the system for 8 way and 16 way performance.
>> That's a mistake.
>And you are proposing a fork for handling exactly this? I don't get it...
[Ah, and I've sworn that I won't participate in this thread again...]
99.99% of your userbase have one or two processors. 99.999% of your
userbase have less than 8 processors.
It simply doesn't make sense to design something for 128+ Processors
if noone uses it. Especially if it puts a penalty on the user base
with one or two processors. Then such a design is actively hurting
your user base. And this is nonsense. That's why the design goes
1->2->4->8. We got SMP once a core developer got a sponsored SMP
board. Not because Linus designed his OS with "I want to scale to lots
of processors I can only dream of". Along that road lies madness (and
maybe GNU Hurd ;-) ).
I actually have five (at a customers site) eight-way machines.
Unfortunately now they all run Windows 2000 (Datacenter Edition
(TM)). But if the "eight-way" support would hurt the "two way"
machines, I'd advocate to put that code at least under a compile
switch.
Actually I do like the idea in Larrys' paper. It doesn't hurt beyond
eight way, because the next eight processors are their own
"system". Just because it doesn't hurt the smaller boxes (much).
Regards
Henning
-- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.deAm Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/