Wie viele Kerne kann der Linux-Kernel verwalten?

Ich interessiere mich für theoretische Grenzen, vielleicht mit Beispielen für Systeme mit einer großen Anzahl von CPUs.

Mindestens 2048 in der Praxis. Als konkretes Beispiel verkauft SGI sein UV- System, das 256 Sockel (2.048 Kerne) und 16 TB gemeinsam genutzten Speicher unter einem einzigen Kernel verwenden kann. Ich weiß, dass es mindestens einige Systeme gibt, die in dieser Konfiguration verkauft wurden.

Laut SGI:

Altix UV läuft unter völlig unverändertem Linux, einschließlich der Standarddistributionen von Novell und Red Hat.

Dies ist, was Launchpad über Ubuntu zu sagen hat, also denke ich, dass es auf andere zutrifft:

1.Intel x86:
Maximum CPUs: 32 (including logical CPUs)
Maximum memory: 64GB
Maximum filesize: 8TB
Maximum filesystem size (ext3) 16TB
Maximum per-process virtual address space: 4GB

2.AMD64/EM64T:
Maximum CPUs: 64
Maximum memory: 128GB
Maximum filesize: 8TB
Maximum filesystem size (ext3): 16TB
Maximum per-process virtual address space: N/A

These are standard max limitations whereas Linux cluster systems can scale up to 1024 CPU's.

Das sind 32 oder 64 CPUs für x86 bzw. x86_64.

Redhat sagt dasselbe, aber in einer Management-freundlichen Tabelle . Redhat EL6 kann 32 für x86- oder 128- oder 4096-CPU-Kerne für x86_64 ausführen.

Der x86_64-Linux-Kernel kann maximal 4096 Prozessorthreads in einem einzelnen Systemabbild verarbeiten. Dies bedeutet, dass bei aktiviertem Hyper-Threading die maximale Anzahl von Prozessorkernen 2048 beträgt. Ja, es gibt Computer mit mehr als 2048 Prozessorkernen. Diese werden jedoch als Cluster ausgeführt, in denen mehrere Linux-Kernel zusammenarbeiten, die über eine Hochgeschwindigkeitsverbindung, normalerweise eine Infiniband-Fabric, verbunden sind.

aus dem aktuellsten Kernel 3.13 in ~ / arch / x86 / Kconfig:

config NR_CPUS

    ---help---
      This allows you to specify the maximum number of CPUs which this
      kernel will support.  If CPUMASK_OFFSTACK is enabled, the maximum
      supported value is 4096, otherwise the maximum value is 512.  The
      minimum value which makes sense is 2.

      This is purely to save memory - each supported CPU adds
      approximately eight kilobytes to the kernel image.

Update: Auf neueren Kerneln ist dies architekturspezifisch - zum Beispiel können Sie auf 4.15 x86_64 NR_CPUS unter den richtigen Umständen auf 8192 setzen, während 32-Bit-Arm bei 32 stoppt .

Dieses Baby rennt 10.368!

Threads unterliegen dem Multitasking-Modell und dem Thread-Management-Schema. Das Gdt von Intel-basierten Systemen wird unter Linux verwendet, wenn ich mich recht erinnere. Die Idee ist, es hat eine Möglichkeit 8192 Fäden bei maximaler Größe. Dies setzt voraus, dass das System das GDT verwendet, um die Threads zu verwalten. Auf 32-Bit-Maschinen wird das Task-Switching verwaltet, und die Interrupt-Vektoren auf 32- und 64-Bit-Maschinen müssen gdt-Einträge haben. Ich bin nicht sicher, wie der Arm es macht, aber die gleiche Artikulation muss erreicht werden. Task-Switching-Konzepte iterieren die GDT in Tasking-Modellen.

Wenn Sie aus dem gdt-Schema ausbrechen, können Sie wahrscheinlich das erreichen, wofür Sie Speicher haben, wenn Sie für jeden Thread einen Seitenstapelrahmen, eine Seitencodebasis für den Thread und eine Seite mit Heapspeicherplatz haben. Sie können nicht davon ausgehen, dass Sie eine Seite mit Code oder Heap haben, bei der es sich um Zufallsvariablen handelt. Im Allgemeinen gibt es zwei Stack-Frames für jeden Thread, einen vom Thread und einen vom Linux-Kernel. Sie fügen virtuelle Speicherkonzepte des Swap Space hinzu und das Modell wird aus dem Wasser gesprengt, aber es geht um Thread-Priorität.

Ebenfalls:

Wenn Sie ein Linux als Controlling auf der UV-SGI verwenden und die Bladecenter mit ihrem eigenen 4.15-Kernel verwenden, können Sie im Moment Folgendes verwenden:

4096 Klingenständer. 1 Rack mit 1024 Core x 4096 Cores. Diese Konfiguration wird im Moment der höchste Core sein, der unter Linux verwendet wird. Sie können alle Kerne unter Red Hat steuern.