Non-Uniform Memory Access

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von CcNUMA)
Zur Navigation springen Zur Suche springen

Non-Uniform Memory Access oder kurz NUMA ist eine Computer-Arbeitsspeicher-Architektur für Multiprozessorsysteme, bei denen jeder Prozessor einen eigenen, „lokalen“ Arbeitsspeicher hat, aber anderen Prozessoren über einen gemeinsamen Adressraum „direkten“ Zugriff darauf gewährt (Distributed Shared Memory). Die Speicherzugriffszeiten für eine CPU in einem solchen Verbund hängen daher davon ab, ob sich eine Speicheradresse im CPU-eigenen „lokalen“ oder im „fremden“ Speicher (einer anderen CPU) befindet.

Im Gegensatz dazu stehen

  • Uniform-Memory-Access (UMA), bei dem es einen zentralen Speicher gibt, auf den Zugriffszeiten immer gleich sind.
  • No-Remote-Memory-Access (NoRMA), bei dem kein direkter Zugriff auf den fremden Speicher erlaubt ist und jeder Prozessor seinen eigenen Adressraum benutzt.
  • Cache-only-Memory-Access (CoMA), bei dem wie bei NUMA ein gemeinsamer Adressraum sowie für jeden Prozessor separat lokaler Speicher existiert, andere Prozessoren jedoch nicht auf den „entfernten“ Speicher schreiben, sondern diesen (ähnlich wie bei Caches) in ihren lokalen Speicher übertragen, woraufhin dieser an seiner vorigen Position gelöscht (invalidiert) wird. D. h. bei einem Schreibzugriff auf eine Speicherseite wird die schreibende CPU zum Besitzer der Speicherseite, und die Seite wird in den lokalen Arbeitsspeicher dieser CPU transferiert.

NUMA-Architekturen sind der nächste Schritt zur Erhöhung der Skalierbarkeit der SMP-Architekturen.

Cache-coherent NUMA (ccNUMA)

[Bearbeiten | Quelltext bearbeiten]

Fast alle Rechnerarchitekturen benutzen eine kleine Menge sehr schnellen Speichers, der als Cache bezeichnet wird, um bei Speicherzugriffen Lokalitätseigenschaften auszunutzen. Bei Verwendung von NUMA sorgt das Beibehalten der Cache-Kohärenz über den verteilten Speicher für zusätzlichen Overhead. Als Beispiel stelle man sich vor, dass sich ein Prozessor Daten aus dem Speicher eines anderen Prozessors holt, damit Berechnungen anstellt und die Ergebnisse in seinen lokalen Cache schreibt. Der Cache des Prozessors, von dem die Daten stammen (und vielleicht auch noch weitere Caches im System) müssen dann synchronisiert werden.

Nicht Cache-kohärente NUMA-Systeme sind zwar einfacher zu entwickeln und zu bauen, aber mit dem Standard-Programmiermodell von Neumanns nur schwer programmierbar. Daher besitzen alle derzeit im Einsatz befindlichen NUMA-Systeme spezielle Hardware, um die Cache-Kohärenz sicherzustellen, und werden deshalb auch als cache-coherent NUMA (ccNUMA) bezeichnet.

Dies wird meistens durch Inter-Prozessor-Kommunikation zwischen den Cache-Controllern erreicht, die so für kohärente Speicherinhalte sorgen, falls die gleiche Speicherstelle in mehr als einem Cache gespeichert ist. ccNUMA leidet unter schlechter Performance, wenn mehrere Prozessoren schnell nacheinander auf dieselbe Speicherstelle zugreifen wollen. Daher versucht ein Betriebssystem mit NUMA-Unterstützung die Häufigkeit solcher Zugriffe zu minimieren, indem Prozessoren und Speicher auf NUMA-freundliche Art und Weise alloziert werden: zusammengehörige Threads werden bevorzugt den CPU-Kernen immer desselben Prozessors zugeordnet; wenn sie Speicher anfordern, erhalten sie vorzugsweise Speicher dieses Prozessors.

Aktuelle Implementationen von ccNUMA-Systemen sind beispielsweise AMD-Mehrprozessorsysteme auf Opteron-Basis und SGI-Systeme mit NUMAlink. Frühere ccNUMA-Systeme basierten auf dem Alpha-Prozessor EV7 der Digital Equipment Corporation (DEC) oder den MIPS-R1x000-Prozessoren wie etwa in der SGI-Origin-Serie.

NUMA vs. Cluster-Computing

[Bearbeiten | Quelltext bearbeiten]

Im Unterschied zu NUMA-Computern verfügt jeder Cluster-Knoten über einen eigenen Adressraum. Weiterhin sind die Kommunikationslatenzen zwischen Cluster-Knoten deutlich höher als die zwischen NUMA-gekoppelten Prozessoren.

Durch entsprechende Anpassungen im Betriebssystem beim Paging des virtuellen Speichers ist es möglich, clusterweite Adressräume zu implementieren, und somit „NUMA in Software“ umzusetzen. Da die hohen Latenzen jedoch bestehen bleiben, ist dies nur selten von Nutzen.


Der Original-Artikel aus der englischen Wikipedia enthält Material von FOLDOC, das hier und in der engl. Wikipedia unter einer Public-Domain-Lizenz verwendet wird.