Windows 7 192/256 Kerne/CPUs vs Linux 4096 Kerne/CPUs

[Linux Kernel Oops]

K.w.T.

[irata_]

Ist das so?
Und sind 4096 ein Hardware- oder Software-Limit?

[Autor]

Und wenn schon, mir sind keine x68/x64-Systeme bekannt, die 192 Kerne haben. Und das wird auch noch lange so bleiben, bis das mal interessant wird, reden wir schon von Windows 10 oder noch höher.

[hux]

Es gibt hier nur einen großen Unterschied bei den Systemen. Die 256 Kerne/Cpus die der NT Kernel verwenden kann, sind Limits die zu Compilezeiten gesetzt werden. Das hat erstmal nichts mit Limitierung der Architektur zu tun, aber Microsoft ist (da unmittelbar sie Support für ihre Platform geben müssen) in der Position nur Software und entsprechende Konfigurationen rausgeben zu können (und zu wollen), die sie auch testen und supporten können. Die Anwendungsgebiete von Rechner mit mehr als 256 CPUs ist aber derart klein, dass es einfach wichtigeres in einem kommerziellen Unternehmen gibt, als Unsummen für das Supporten solcher vereinzelten Systeme zu investieren. Hier konzentriert man sich lieber auf Verbesserungen, die der breiten Masse zu Gute kommen.

[Linux Kernel Oops]

hux schrieb:
--------------------------------------------------------------------------------
> Es gibt hier nur einen großen Unterschied bei den Systemen. Die 256
> Kerne/Cpus die der NT Kernel verwenden kann, sind Limits die zu
> Compilezeiten gesetzt werden. Das hat erstmal nichts mit Limitierung der
> Architektur zu tun, aber Microsoft ist (da unmittelbar sie Support für ihre
> Platform geben müssen) in der Position nur Software und entsprechende
> Konfigurationen rausgeben zu können (und zu wollen), die sie auch testen
> und supporten können. Die Anwendungsgebiete von Rechner mit mehr als 256
> CPUs ist aber derart klein, dass es einfach wichtigeres in einem
> kommerziellen Unternehmen gibt, als Unsummen für das Supporten solcher
> vereinzelten Systeme zu investieren. Hier konzentriert man sich lieber auf
> Verbesserungen, die der breiten Masse zu Gute kommen.

Ich verweise auf...

http://forum.golem.de/kommentare/applikationen/microsoft-will-die-revolution-des-os-fuer-mehrkern-cpus/...die-meisten-betriebssysteme.../40137,2174892,2175956,read.html#msg-2175956

[Satz mit X]

Du verwechselt da wahrscheinlich etwas, ich kenne zumindest kein Board welches 256 Kerne und eine Windows-Kompatible Architektur unterstützt. Die Supercomputer sind alle Cluster und auf jedem Knoten läuft ein eigenes Betriebssystem. Das gilt sowohl für Windows, wie auch für Linux. Dabei werden in der Regel handelsübliche Serverboards benutzt, die über eine HighSpeed-Netzwerk-Verbindung gekoppelt sind. Bei einem Viersockelboard, mit 4x6 Kernern, wären das 24 Kerne pro Node und das dürfte ein Serverwindows spielend hinbekommen.
Ich habe jetzt auch kein Chips finden können die wirklich in die Größenordnung (>200) kommen, ausser GPUs.

[hux]

Bis inkl. NT 6.0 war der Kernel auf 32 Kerne/CPUs auf 32 Bit Systemen und auf 64 Kerne/CPUs bei 64 Bit Systemen beschränkt. Das lag daran, dass man z.B. die AffinityMask, die angibt auf welchen Kernen ein Thread laufen darf, aus Performancegründen mit der Wortbreite der CPU-Architektur gekoppelt hat:

>typedef struct _KTHREAD {
> ...
> KAFFINITY Affinity;
> ...
>} KTHREAD, *PKTHREAD, *PRKTHREAD;

mit

>typedef ULONG_PTR KAFFINITY;

Das macht Sinn, da es in der X86-Architektur einen Maschinenbefehl (bsfq -> 64 Bit BitScanForward) gibt, der die Position der ersten 1 angibt. So lässt sich mit einem einzigen Befehl ein möglicher Zielprozessor ausmachen.

Unter Linux ist dagegen die CPU-Maske als beliebig langes Bitmap (Array aus ulongs) definiert und kann deswegen natürlich auch beliebig viele CPUs aufnehmen:

>typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;

mit

>#define DECLARE_BITMAP(name,bits) \
> unsigned long name[BITS_TO_LONGS(bits)]

und

>#define NR_CPUS CONFIG_NR_CPUS

wobei CONFIG_NR_CPUS zur Compilezeit gesetzt wird.

Diese Konstruktion wäre unter Windows genauso möglich gewesen, da im Kernel ebenfalls Bitmapstrukturen verwendet werden (z.B. für das Speichermanagement). Man hat sich jedoch bewusst dagegen entschieden, da die komplexeren Strukturen zwar mehr Spielraum geben, aber auf 99% der Systeme (eben solchen mit <= 32/64 Kernen) zu unnützer Performancedegradion führen.

Mittlerweile sind die Anforderungen gestiegen und zu den 99% der Systeme zählen heute auch Maschinen mit 256 Kernen. Und wie ich bereits geschrieben habe, macht es durchaus Sinn sich Problemstellungen wie dieser hier erst zu stellen, wenn es auch einen technischen Hintergrund dafür gibt. Wir wollen hier schließlich keine Schw...längenvergleiche machen, sondern die Entwicklungskapazitäten auf das Wesentliche fokussieren.

Unter NT 6.1 werden die CPUs nun nach NUMA-Nodes gruppiert, wobei jede NUMA-Gruppe wieder eine der Wortbreite der CPU-Architektur entsprechende Anzahl von CPUs haben kann. So bleibt der Performancegewinn erhalten (da immernoch nur ein einzelner Maschinenbefehl nötig ist), wobei die maximale Anzahl der Kerne/CPUs von der Anzahl der NUMA Gruppen abhängt. Diese widerum kann zur Compilezeit festgelegt werden, ist aber zur Zeit auf 4 Gruppen gesetzt: 4 * 64 = 256.

Systeme mit mehr als 256 Kernen und passenden Anwendungen sind heute noch derart rar, dass es kaum einen Sinn macht das Limit über diese Grenze zu erhöhen, gleichwohl der Kernel auch über diesen Wert noch gute Skalierung liefern kann (Zugegeben auch erst set NT 6.1 durch Entfernen einiger zentraler Locks). Man schaltet aber nicht frei, was man nicht offiziell supporten will, da damit natürlich auch Kosten verbunden sind. Linux fährt da eine etwas andere Philosophie. Hier werden auch 4096 Kerne freigeschaltet, selbst wenn der Kernel in dem Bereich hauptsächtlich mit Lock contention zu kämpfen hat. Hier steht nunmal auch kein Support dahinter und es kann vorkommen, dass man sich von heute auf morgen mit dem CF Scheduler anfreunden muss.

Du solltest also einmal davon Abstand nehmen, vorschnell zu urteilen. So ziemlichen allen Eigenheiten beider Systeme liegen fundierte technische Grundlagen und entsprechende Designentscheidungen zu Grunde. Weder bei Windows noch bei Linux sind unfähige Leute am Werk.

Du dagegen beweißt nicht sehr viel Tiefgang:
>Gratulation Microsoft ihr seid jetzt auf dem Stand von vor 10 Jahren, denn das konnte schon Linux 2.4.x!

Ich möchte dich darauf hinweisen, dass der 2.4er Linuxkernel nichtmal einen O(1) Scheduler besaß und massiv mit unangemessenem Work Stealing zu kämpfen hatte. Und bis heute z.B. beherrscht der Linuxkernel keine vollständig asynchrone I/O, keine Layered I/O und der Performanceoverhead für preemptive Kernelthreads ist derart hoch, dass dieses Feature nur bei Server aktiviert ist, um kurze Antwortzeiten zu erreichen. Es gibt also auch hier genügend Baustellen.

Grüße,
hux

[wodar]

hey, just for fun, kennst du gute bücher/papers aus dem bereich die sich lohnen durchgesehen zu werden?

[hux]

Passenderweise habe ich eben eine Liste gepostet:
http://forum.golem.de/kommentare/applikationen/microsoft-will-die-revolution-des-os-fuer-mehrkern-cpus/ihr-benehmt-euch-hier-fast-alle-wie-pubertierende-kids/40137,2176525,2178215,read.html#msg-2178215

Viel Spaß damit!

[wodar]

dann vielen dank :)

[Linux Kernel Oops]

Und nun erklär mal warum MS an Barrelfish arbeitet, deinen Ergüssen zufolge wäre das ja unnötigt da:

a) MS nur "vertreibt" was sie supporten können
b) MS sich nur darum kümmert wenn es so weit ist
c) NT auch noch gut ausserhalb der 256 Grenze skaliert

Also warum brüstet sich MS mit dem Barrelfish Project und wie super skaliert wird und warum sieht man in der PDF keinen vergleich zu NT?



Btw. Ich würde gern mal Window HPC 2008 auf einem SGI Altix 4700 sehen.

[hux]

Ganz einfach, weil man natürlich auch radikal andere Ansätze _erforschen_ will. Barrelfish ist ein Forschungsprojekt. Das ist schließlich nicht die Entwicklung von Windows, wo man in diesem Moment bereits unmittelbare kommerzielle Interessen verfolgt. Hier basiert ein ganzes Ecosystem auf Windows. Da muss man mit Experimenten auch vorsichtig sein. Daher wird auch nur freigegeben, was man wirklich support kann und will. Zumal dass NT bisher gut skaliert, heißt ja nicht, dass es das auch in einer 8K CPU Umgebung noch kann. Vielleicht stößt man dort auf Effekte, die mit den heutigen Denkansäßen einfach immer auf zu großen Leistungsverlust stoßen. Daher ja auch das Thema dieses Artikels und Dave Proberts Ideen zum Thema Multiprozessoren. Mal abgesehen davon, dass Barrelfish ein Versuch für einen distributed Kernel ist, der auf mehreren unterschiedlichen Prozessortypen gleichzeitig läuft (z.B. CPU und GPU). Für so etwas ist NT nicht konzipiert worden.

[Linux Kernel Oops]

hux schrieb:
--------------------------------------------------------------------------------
> Ganz einfach, weil man natürlich auch radikal andere Ansätze _erforschen_
> will. Barrelfish ist ein Forschungsprojekt. Das ist schließlich nicht die
> Entwicklung von Windows, wo man in diesem Moment bereits unmittelbare
> kommerzielle Interessen verfolgt. Hier basiert ein ganzes Ecosystem auf
> Windows. Da muss man mit Experimenten auch vorsichtig sein. Daher wird auch
> nur freigegeben, was man wirklich support kann und will. Zumal dass NT
> bisher gut skaliert, heißt ja nicht, dass es das auch in einer 8K CPU
> Umgebung noch kann. Vielleicht stößt man dort auf Effekte, die mit den
> heutigen Denkansäßen einfach immer auf zu großen Leistungsverlust stoßen.
> Daher ja auch das Thema dieses Artikels und Dave Proberts Ideen zum Thema
> Multiprozessoren. Mal abgesehen davon, dass Barrelfish ein Versuch für
> einen distributed Kernel ist, der auf mehreren unterschiedlichen
> Prozessortypen gleichzeitig läuft (z.B. CPU und GPU). Für so etwas ist NT
> nicht konzipiert worden.

Für sowas ist Linux auch nicht konzipiert trotzdem wird in den Benchmarks Linux mit Barrelfish verglichen und NT sieht man nirgends...


Warum wohl scheut NT den Vergleich in den PDFs?
Warum sagt MS Barrelfisch skaliert so super toll?

Weil NT vielleicht doch nicht so dicke skaliert und das ist die EINZIGE Schlussfolgerung!