DE102009016742B4 - Mehrprozessor-Computersystem - Google Patents

Mehrprozessor-Computersystem Download PDF

Info

Publication number
DE102009016742B4
DE102009016742B4 DE102009016742A DE102009016742A DE102009016742B4 DE 102009016742 B4 DE102009016742 B4 DE 102009016742B4 DE 102009016742 A DE102009016742 A DE 102009016742A DE 102009016742 A DE102009016742 A DE 102009016742A DE 102009016742 B4 DE102009016742 B4 DE 102009016742B4
Authority
DE
Germany
Prior art keywords
computer system
resource manager
multiprocessor computer
resources
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102009016742A
Other languages
English (en)
Other versions
DE102009016742A1 (de
Inventor
Rolf Prof. Dr.-Ing. Ernst
Jonas Dipl.-Ing. Diemer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Innovationsgesellschaft Technische Universitae De
Original Assignee
TECH UNI BRAUNSCHWEIG CAROLO WILHELMINA
Technische Universitaet Braunschweig
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by TECH UNI BRAUNSCHWEIG CAROLO WILHELMINA, Technische Universitaet Braunschweig filed Critical TECH UNI BRAUNSCHWEIG CAROLO WILHELMINA
Priority to DE102009016742A priority Critical patent/DE102009016742B4/de
Priority claimed from DE200910061066 external-priority patent/DE102009061066A1/de
Priority to US12/757,411 priority patent/US8515797B2/en
Publication of DE102009016742A1 publication Critical patent/DE102009016742A1/de
Application granted granted Critical
Publication of DE102009016742B4 publication Critical patent/DE102009016742B4/de
Priority to US13/903,320 priority patent/US9268618B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/50Indexing scheme relating to G06F9/50
    • G06F2209/5014Reservation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Betrieb eines Mehrprozessor-Computersystems, das wenigstens zwei Mikroprozessoren (102) sowie von den Mikroprozessoren gemeinsam genutzte Ressourcen (103, 104, 105, 106, 107, 108) aufweist, wobei auf dem Computersystem Programme (403) ausführbar sind, gekennzeichnet durch wenigstens einen Ressourcen-Manager (101) mit folgenden Merkmalen: a) der Ressourcen-Manager (101) verwaltet ihm zugeordnete, zumindest bezüglich ihres Zeitverhaltens einstellbare Ressourcen (103, 104, 105, 106, 107, 108), b) der Ressourcen-Manager (101) empfängt und verarbeitet von Programmen (403) gesandte Reservierungsanfragen (401) zur Reservierung gewünschter Ressourcen (103, 104, 105, 106, 107, 108), c) die Reservierungsanfragen (401) beschreiben wenigstens Art, Umfang und Zeitverhalten der gewünschten Ressourcen (103, 104, 105, 106, 107, 108), d) der Ressourcen-Manager (101) teilt dem anfordernden Programm (403) die jeweils gewünschten Ressourcen (103, 104, 105, 106, 107, 108) zu, sofern diese verfügbar sind, e) der Ressourcen-Manager (101) stellt das Zeitverhalten der zugeteilten Ressourcen (103, 104, 105, 106, 107, 108) gemäß dem mit der Reservierungsanfrage (401) angeforderten Zeitverhalten ein.

Description

  • Die Erfindung betrifft ein Mehrprozessor-Computersystem gemäß dem Oberbegriff des Patentanspruchs 1. Ferner wird ein vorteilhaftes Verfahren für ein solches Mehrprozessor-Computersystem angegeben.
  • Mehrprozessor-Computersysteme haben die Eigenschaft, dass die vorhandenen Ressourcen des Systems von den Mikroprozessoren gemeinsam genutzt werden. Dies führt bei bekannten Mehrprozessor-Computersystemen dazu, dass die Ausführungszeit für Programme auf Grund der nicht genau vorhersagbaren Auslastung der Ressourcen variiert und damit schwer vorhersagbar ist.
  • Als Ressourcen eines Computersystems werden beispielsweise Hardwarekomponenten verstanden, wie der Hauptspeicher, Kommunikationsmedien (z. B. Datenbus), Ein- und Ausgabekanäle, Cache-Speicher und ggf. andere verwendete Hardware- und Softwarekomponenten, einschließlich Hardwarekomponenten, die sich auf demselben Chip wie die Prozessoren befinden können.
  • In bestimmten Anwendungsbereichen heutiger und künftiger Computersysteme (z. B. Multimedia) ist es notwendig, die Ausführungszeit von Softwareprogrammen oder Teilen davon möglichst exakt vorauszusagen, um beispielsweise Echtzeitanforderungen zu erfüllen oder den Programmablauf zu optimieren. Diese Ausführungszeit wird durch Zugriffe auf eine komplexe Speicherhierarchie mitbestimmt, welche sich aus einem oder mehreren Hauptspeicher-Controllern und/oder anderen Ein-/Ausgabe Schnittstellen, einem oder mehreren Kommunikationsmedien (z. B. in Form eines Networks-On-Chip; NoC) sowie einer Hierarchie aus jeweils einem oder mehreren Cache-Speichern pro Hierarchieebene zusammensetzt. Insbesondere die Cache-Speicher weisen ein stark dynamisches Verhalten auf, was die Vorhersage des Zeitverhaltens sehr erschwert. Darüber hinaus können in Mehrprozessor-Computersystemen die Komponenten der Speicherhierarchie von mehreren Mikroprozessoren und somit auch von unabhängigen Softwareprogrammen gemeinsam genutzt werden, was zu Zugriffskonflikten führen kann, welche das Zeitverhalten von Programmausführungen ebenfalls stark beeinflussen können. Diese Beeinflussung hängt nicht nur vom Verhalten eines einzelnen Softwareprogramms ab, sondern auch davon, wie sich andere, gleichzeitig ausgeführte Softwareprogramme verhalten und wie einzelne Ressourcen ihre jeweiligen Zugriffskonflikte auflösen. Die gegenseitige Beeinflussung ist daher bei den bekannten Mehrprozessor-Computersystemen nur sehr ungenau vorhersagbar, sodass beim Zugriff auf gemeinsame Ressourcen eine Überschätzung der Laufzeit der Software-Programme erfolgt, da bei konservativer Schätzung immer von der höchst möglichen Beeinflussung ausgegangen werden muss. Dies führt dazu, dass das System entweder stark überdimensioniert wird oder die Software-Programme nicht mit garantiertem Zeitverhalten ausführbar sind. Anders gesagt, wenn es möglich ist, alle benötigten Ressourcen so zu reservieren, dass keine Beeinflussung möglich ist, wäre eine Überschätzung der Laufzeit nicht erforderlich. In derzeitigen Mehrprozessor-Computersystemen ergibt sich somit eine schlechte Ausnutzung der verfügbaren Ressourcen, wenn das Zeitverhalten der Anwendungen genau vorhersagbar sein soll.
  • In so genannten eingebetteten Systemen (embedded systems) mit Echtzeitanforderungen ist es bekannt, die Ressourcen fest bestimmten Mikroprozessoren oder Programmen zuzuordnen, um entsprechende Konflikte zu vermeiden. Statt Cache-Speichern werden dort vorzugsweise softwareverwaltete Speicher, so genannten Scratch-Pad-Memories (SPM, vgl. Dokument D1 in der Literaturliste), eingesetzt, welche ein einfaches deterministisches Zeitverhalten haben. Hiermit können zwar relativ effektiv die Echtzeitanforderungen erfüllt werden, das System ist aber in der Regel ziemlich anwendungsspezifisch und nicht für einen universellen Einsatz geeignet. Ein solches System eignet sich insbesondere nicht für den effizienten Einsatz für allgemeinere Aufgaben, z. B. in Desktop- und Serversystemen. Außerdem führen solche Anpassungen meist zu einer ineffizienten Systemnutzung.
  • Aus der Veröffentlichung von Ray, S. et al.: „A reconfigurable bus structure for muliprocessors with bandwidth reuse. In: Journal of Systems Architecture, Vol. 45, No. 11, May 1999. pp. 847–862, Abstract” ist eine rekonfigurierbare Busstruktur beschrieben, bei der eine Methode zur Ausnutzung von Busbandbreiten beschrieben wird, bei der zeitliche und räumliche bzw. spektrale Bandbreitenerweiterungen ohne Pufferverzögerungen genutzt werden können.
  • Der Erfindung liegt daher die Aufgabe zu Grunde, ein Mehrprozessor-Computersystem mit von den Mikroprozessoren gemeinsam genutzten realen Hardware-Ressourcen und ein Verfahren dafür anzugeben, das ein deterministisches Zeitverhalten der auf dem Computersystem ausgeführten Programme erlaubt. Die Ausführungszeit von Programmen soll somit vorhersagbar sein.
  • Diese Aufgabe wird durch die in dem Patentanspruch 1 angegebene Erfindung gelöst. In dem Patentanspruch 15 ist ein vorteilhaftes Verfahren für ein Mehrprozessor-Computersystem angegeben. Die Unteransprüche enthalten vorteilhafte Ausführungsformen der Erfindung.
  • Die Erfindung hat den Vorteil, eine zur Laufzeit des Computersystems und somit eine von Programmen konfigurierbare, definierte Zuteilung aller benötigten Ressourcen zu ermöglichen. Hierdurch wird das Zeitverhalten von Zugriffen, insbesondere auf die Speicherhierarchie, vorhersagbar gemacht. Darüber hinaus wird ein effizienter, vorhersagbarer Datentransport im Hintergrund ermöglicht. Kern der Erfindung ist hierbei ein zentraler Ressourcen-Manager (nachfolgend RM genannt), welcher die Zuteilung von Ressourcen koordiniert. Der RM ist als separate Hardware-Komponente des Computersystems implementiert. Eine Implementierung des RM als Hardware-Komponente ist vorteilhaft auch in Form einer Implementierung auf dem selben Chip wie die Prozessoren möglich, also auf einem Multiprocessor-System-On-Chip bzw. einem Chip-Multiprocessor.
  • Vorteilhaft verwaltet der RM ihm zugeordnete, zumindest bezüglich ihres Zeitverhaltens einstellbare Ressourcen. Durch die Einführung von Reservierungsanfragen, die neben Art und Umfang gewünschter, zu reservierender Ressourcen auch deren Zeitverhalten beschreiben, wird der RM in die Lage versetzt, ein Ressourcen-Management auch hinsichtlich der Ausführungszeiten von Programmen durchzuführen. Vorteilhaft stellt der RM das Zeitverhalten der zugeteilten Ressourcen gemäß dem angeforderten Zeitverhalten einer Reservierungsanfrage ein. Hierdurch garantiert der RM eine definierte Ausführungszeit, wie in der Reservierungsanfrage angefordert, und somit ein deterministisches Zeitverhalten derjenigen Programme, die Reservierungen durchführen.
  • Die Parameter einer Reservierungsanfrage sind dabei je nach gewünschter Ressource definiert. Sofern als Art der Ressource beispielsweise Cache-Speicher angefordert wird, wird als Umfang die gewünschte Speichergröße in KB oder MB angegeben. Als Zeitverhalten wird die Zugriffslatenz angegeben. Für den Fall, dass als Art der Ressource ein Kommunikationsmedium angefragt wird, wird als Umfang das zu übertragende Datenvolumen (z. B. in MB) und als Zeitverhalten die gewünschte Übertragungszeit oder bei mehrfacher Übertragung die Übertragungsrate und -latenz angegeben. Die Einstellung des Zeitverhaltens schließt auch die Behandlung von Zugriffskonflikten bei gemeinsamer Nutzung von Ressourcen durch mehrere Prozessoren ein. Hierfür sind die Ressourcen für eine solche Behandlung von Zugriffskonflikten einstellbar, z. B. derart, dass die verfügbare Kapazität einer Ressource anteilig verschiedenen Prozessoren bzw. anfragenden Programmen zugeordnet wird.
  • In einer vorteilhaften Ausgestaltung der Erfindung kann der RM pro Reservierungsanfrage mehr als eine Ressource reservieren. Dies hat den Vorteil, dass die Reservierungsanfragen eine funktionale Beschreibung der gewünschten Ressourcen enthalten können und nicht unbedingt hardwarespezifisch sein müssen. So muss eine Reservierungsanfrage beispielsweise nicht unbedingt die Anforderung enthalten, dass eine bestimmte Speicherplatzgröße mit einer bestimmten Zugriffszeit sowie bestimmte Zugriffszeiten auf die Kommunikationsmedien reserviert werden. Vielmehr kann die Reservierungsanfrage eine funktionale Beschreibung der gewünschten Ressourcen enthalten, etwa für das Abspielen einer Multimediadatei. Der RM wählt dann automatisch die erforderlichen Ressourcen aus, z. B. Cache-Speicher für eine Zwischenspeicherung, Kommunikationsmedien-Zugriffszeiten sowie Ein-/Ausgabekanäle, stellt diese entsprechend dem angeforderten Zeitverhalten ein und reserviert die entsprechenden Kapazitäten dieser Hardware-Ressourcen.
  • Gemäß der Erfindung beschreiben die Reservierungsanfragen virtuelle Ressourcen. Der RM wählt automatisch diejenigen realen Ressourcen aus und teilt sie zu, die zur Erfüllung einer Reservierungsanfrage erforderlich sind. Eine virtuelle Ressource kann beispielsweise ein virtueller Prozessor sein, d. h. eine bestimmte Rechenkapazität eines realen Mikroprozessors der Hardware. Die Bereitstellung solcher virtueller Ressourcen erlaubt es dem Anwender bzw. dem Programmierer, die Programme weitgehend unabhängig von einer bestimmten Hardwareausstattung des Mehrprozessor-Computersystems zu entwickeln, da sich der RM automatisch um die Zuordnung und das Management realer Hardware-Ressourcen kümmert.
  • Gemäß einer vorteilhaften Weiterbildung der Erfindung verfügt der RM über ein System-Modell, das wenigstens die von dem RM verwalteten Ressourcen hinsichtlich Art, Kapazität sowie Zugriffslatenz und Zugriffsbandbreite beschreibt. Die Verwendung des System-Modells hat den Vorteil, dass das Ressourcen-Management auf einfache und effiziente Weise möglich wird. Insbesondere sind auch Änderungen der Hardware-Konfiguration des Mehrprozessor-Computersystems unproblematisch, da hinsichtlich des RM lediglich das System-Modell aktualisiert werden muss. Das System-Modell spiegelt sozusagen ein Abbild des Systems wieder. Das System-Modell kann beispielsweise in einem Flash-Speicher abgelegt sein.
  • Gemäß einer vorteilhaften Weiterbildung der Erfindung werden als Ressourcen virtuelle Ressourcen bereitgestellt, die virtuelle Scratch-Pad-Memories (nachfolgend SPM genannt) mit direktem Speicherzugriff (direct-memory-access, nachfolgend DMA genannt) enthalten. Vorteilhaft wird das im Bereich eingebetteter Systeme genutzte Programmiermodel der SPM's mit DMA-Transfers verwendet, also ein virtuelles SPM im Cache bereitgestellt, auf das über einen DMA-Controller zugegriffen werden kann. Der RM stellt den Programmen ein Interface zur Reservierung von virtuellen Komponenten mit deterministischen Eigenschaften zur Verfügung, z. B. ein virtuelles SPM mit fester Größe und garantierter Zugriffsbandbreite und -latenz oder einen virtuellen DMA-Transfer zwischen virtuellem SPM und Hauptspeicher mit garantierter maximaler Ausführungsdauer. Auf diese Weise können virtuelle eingebettete Subsysteme mit definiertem Zeitverhalten innerhalb des Gesamtsystems erzeugt werden.
  • Gemäß einer vorteilhaften Weiterbildung weisen die von dem RM verwalteten Ressourcen wenigstens ein Kommunikationsmedium, z. B. ein Datenbus, einen Speicher oder Speicher-Controller, einen Hardware-Beschleuniger und/oder wenigstens eine Ein- und/oder Ausgabeeinheit auf. Hierdurch ist das erfindungsgemäße Verfahren flexibel auf einer Vielzahl unterschiedlich ausgestatteter Mehrprozessor-Computersysteme einsetzbar.
  • Die Realisierung der Ressourcenzuteilung durch einen zentralen RM hat folgende Vorteile:
    • – Der RM kann anhand eines System-Modells und der Kenntnis existierender Reservierungen prüfen, ob eine Reservierungsanfrage überhaupt erfüllbar ist. Hierbei kann der RM eine Priorisierung durchführen und ggf. bereits erteilte Reservierungen stornieren, um eine wichtigere Reservierungsanfrage zu erfüllen.
    • – Bei fehlerhaftem Verhalten eines reservierenden Programms kann der RM Reservierungen stornieren und so Ressourcen wieder freigeben.
    • – Bei nicht gegebener Erfüllbarkeit einer Reservierungsanfrage kann der RM mit dem anfragenden Programm alternative Reservierungen aushandeln.
    • – Der RM kann bei Kenntnis der Systemauslastung (z. B. durch einen Performance-Counter) die Systemleistung bei einer Reservierung optimieren. Hierfür kann der RM ggf. alternative Reservierungen mit einem anfragenden Programm aushandeln.
    • – Der RM stellt eine Abstraktionsebene für das Programm dar, indem eine von der tatsächlichen Implementierung der Ressourcenzuteilung unabhängige Schnittstelle bereitgestellt wird.
  • Die Erfindung wird nachfolgend anhand von Ausführungsbeispielen unter Verwendung von Zeichnungen näher erläutert.
  • Es zeigen
  • 1 – eine prinzipielle Architektur eines erfindungsgemäßen Mehrprozessor-Computersystems und
  • 2 – ein Mehrprozessor-Computersystem mit virtuellen Ressourcen und
  • 3 – eine Kommunikation bei einer Reservierungsanfrage und
  • 4 – einen Ablauf einer Reservierungsanfrage und
  • 5 – ein konkretes Beispiel einer Reservierungsanfrage eines virtuellen eingebetteten Systems als Sequenzdiagramm und
  • 6 – ein Sequenzdiagramm einer Reservierung eines virtuellen SPMs und
  • 7 – die Architektur eines Netzwerk-Routers.
  • In den Zeichnungen werden gleiche Bezugszeichen füreinander entsprechende Elemente verwendet.
  • Nachfolgend bedeuten die Begriffe Programm, Softwareprogramm, Anwendung oder Applikation jeweils auf dem Computersystem ausführbare Programme jeder Art, insbesondere Anwendungsprogramme und Systemprogramme.
  • Die Erfindung erlaubt es, durch eine dynamische Verwaltung von Ressourcen das Zeitverhalten des Systems – insbesondere das der Speicherhierarchie – für einzelne, als wichtig angesehene Anwendungen vorhersagbar zu machen, diese also von gleichzeitig laufenden Applikationen zu isolieren. Auf diese Weise ist es möglich, Anwendungen, die ein genau vorhersagbares Zeitverhalten benötigen, gleichzeitig mit anderen Anwendungen auf einem System mit gemeinsam genutzten Ressourcen auszuführen.
  • Hierbei werden existierende Mechanismen für einzelne Ressourcen, welche z. B. durch Reservierung oder Priorisierung das Verhalten im Falle von Zugriffskonflikten verbessern, verwendet. Diese werden nun im Folgenden vorgestellt:
  • Cache-Speicher
  • Einige Cache-Architekturen ermöglichen es, durch Umkonfigurierung (D2) oder so genanntes Cache-Locking (D3, D4), also das Festhalten bestimmter Daten im Cache, das Zeitverhalten von Caches selektiv zu vereinfachen. Hierbei verhält sich der Cache dann wie ein softwareverwalteter Speicher. Verschiedene Verfahren mit unterschiedlichen Vor- und Nachteilen (Schaltungsaufwand, Konfigurations-Overhead, Granularität des Locking) existieren.
  • Der gegenseitige Einfluss gleichzeitig ausgeführter Programme kann bei einem gemeinsam genutzten Cache durch so genannte Cache-Partitionierung (D5, D6), also die feste Zuweisung von Teilen des gemeinsam genutzten Caches an bestimmte Prozessoren oder Anwendungen, erreicht werden. Auch hier gibt es zahlreiche unterschiedliche Ansätze.
  • Konkrete Ausprägungen der Erfindung können verteilte Caches enthalten. Über ein so genanntes „Address-Mapping” kann gesteuert werden, welche Adressen welchen Cache-Teilen zugeordnet sind (D7). Diese Funktionalität kann im Kommunikationsmedium implementiert sein.
  • Datentransfers
  • Insbesondere bei der Verwendung von SPMs werden größere Datenmengen unter Ausnutzung bekannter bzw. regelmäßiger Zugriffsmuster oft über das so genannte Direct-Memory-Access-Verfahren (DMA) im Hintergrund in das SPM geschrieben bzw. daraus gelesen. Die entsprechende Steuerung übernimmt hierbei ein DMA-Controller (DMAC), der wiederum von der Applikation gesteuert wird (D8). Eine vorteilhafte Weiterbildung der Erfindung beinhaltet erweiterte DMA-Controller in Form von Datentransfereinheiten (nachfolgend DTE genannt). Diese schwach-konfigurierbaren Einheiten bieten erweiterte Adressmuster, z. B. 2D-, 3D-, 4D-Blocktransfers, Scatter-/Gather-Listen, sowie die Möglichkeit, Cache-Locking und -Partitionierung durchzuführen.
  • Hauptspeicher
  • Konflikte beim Hauptspeicherzugriff werden durch spezielle Ablaufplanung im Hauptspeichercontroller behandelt, wodurch die Datenraten einzelner Applikationen begrenzt bzw. Zugriffe bestimmter Applikationen priorisiert werden können (D9, D10). Auf diese Weise können in gewissen Grenzen die maximale Latenz und/oder der minimale Datendurchsatz für ausgewählte Anwendungen garantiert werden.
  • Kommunikationsmedium
  • Um den Einfluss von Konflikten auf dem Kommunikationsmedium zu eliminieren, existieren insbesondere im Bereich eingebetteter Systeme Networks-on-Chip, welche verschiedene Dienstgüten (Quality-of-Service, QoS) unterstützen. Diese werden in der Regel durch Priorisierung (D11, D12, D13) und/oder Reservierung (D14, D15, D16), von Kommunikationsressourcen realisiert und ermöglichen, gleichzeitig stattfindende Kommunikationen voneinander zu isolieren.
  • Diese Mechanismen haben jedoch den Nachteil, dass diejenige Kommunikation, welche keine strengen Anforderungen an die Dienstgüte stellt, benachteiligt wird. In einem Prozessorsystem trifft dies auf den von Desktop- und Serveranwendungen verursachten Datenverkehr zu. Eine Benachteiligung dieses Verkehrs führt jedoch dazu, dass Anfragen mit einer höheren Latenz belegt sind, was den Durchsatz dieser Anwendungen stark beeinträchtigen kann.
  • Ein vorteilhaftes Kommunikationsmedium, welche diese Effekte reduziert, für ein Mehrprozessor-Computersystem kann z. B. in Form eines in einem Chip integrierten Netzwerks (Network-On-Chip) ausgeführt sein. Das Kommunikationsmedium ist in Bezug auf das Zeitverhalten derart einstellbar, dass ein Hintergrunddatenverkehr vor einem Datenverkehr mit definierten Bandbreitenanforderungen bevorzugt behandelt wird, und ferner ist das Kommunikationsmedium durch Bandbreitenregulierung derart einstellbar, dass ausreichend Bandbreite für den Datenverkehr mit definierten Bandbreitenanforderungen verfügbar ist. Es wird somit unterschieden zwischen einem allgemeinen Datenverkehr, der keine bestimmten Bandbreitenanforderungen hat, und demzufolge als Hintergrunddatenverkehr bezeichnet wird, und dem Datenverkehr mit definierten Bandbreitenanforderungen. Dies erlaubt, dass solcher Hintergrunddatenverkehr je nach Systemauslastung auch vor einem Datenverkehr mit definierten Bandbreitenanforderungen behandelt werden kann. Hierzu wird das Kommunikationsmedium auf eine bestimmte Bandbreite eingestellt.
  • In einer beispielhaften Ausführung eines solchen Kommunikationsmediums handelt es sich um ein on-chip Netzwerk, in welchem die Kommunikation Paket-basiert über eine Vielzahl von Netzwerk-Routern, welche z. B. in einem Gitter (Mesh) angeordnet sind, erfolgt. 7 zeigt einen entsprechenden Netzwerk-Router, welcher drei Verkehrsklassen unterstützt: (1) Garantierte Mindestbandbreite mit nach oben beschränkter Latenz, (2) keine Garantien, aber möglichst geringe Latenz, (3) garantierte maximale Latenz bei nach oben beschränkter Bandbreite. Die Besonderheit findet sich in der Art und Weise, wie einzelne Kommunikationslinks vergeben werden. Hierbei wird zunächst eine bekannte Priorisierung innerhalb der Arbitrierung 705 eingesetzt, bei der jeder Verkehrsklasse separate Puffer (virtuelle Kanäle, vgl. D17) 706, 707 und 708 zugewiesen werden. Um eine maximale Latenz zu garantieren, wird Verkehrsklasse 3 bevorzugt behandelt. Abweichend vom Stand der Technik wird jedoch die Verkehrsklasse 2 vor der Verkehrsklasse 1 bevorzugt behandelt. Um dennoch eine Mindestbandbreite garantieren zu können, werden Bandbreitenbegrenzer (Traffic-Shaper, vgl. D18) 709 eingesetzt, welche bei entsprechender Konfiguration die Bandbreite der Verkehrsklassen 2 und 3 beschränken, so dass im Mittel genug Bandbreite frei bleibt, um die Anforderungen von Verkehrsklasse 1 zu erfüllen. Die Traffic-Shaper sind hierbei als Token-Bucket-Shaper ausgeführt. Abweichend vom Stand der Technik wirken die Traffic-Shaper an den jeweiligen Ausgangsports der Router anstatt an den Eingangsports des Netzwerks, was eine präzise Steuerung der Bandbreite auf bestimmten Verkehrsrouten erlaubt.
  • Darüber hinaus bietet die beschriebene Ausführung der Kommunikationsarchitektur die Möglichkeit des oben beschriebenen Address Mapping. Hierzu bieten die Netzwerk-Adapter, also die Module, welche Netzwerk-Clients an das Netzwerk anbinden, die Möglichkeit der Umsetzung von Adressräumen auf Netzwerkadressen. Dies ermöglicht eine flexible Abbildung von Adressen auf Netzwerkknoten und somit von Speicheradressen auf Teile des verteilten Cache-Speichers (welcher als SPM verwendet werden kann).
  • Zentralisiertes Ressourcen-Management
  • In den oben beschriebenen existierenden Ansätzen werden Ressourcenkonflikte im Cache, Hauptspeicher und Kommunikationsmedium jeweils einzeln behandelt. In der Regel werden jedoch mehrere Ressourcen zusammen verwendet, um eine bestimmte Aufgabe zu erfüllen. Daher ist es für die genaue Analyse des Zeitverhaltens von Zugriffen nötig, die Ressourcenverteilung zu koordinieren.
  • Dies stellt ein mehrdimensionales Optimierungsproblem dar. Für nicht-verteilte Anordnungen, d. h. bei Systemen, in denen jede Ressourcenklasse nur einmal vorhanden ist, existieren bereits einige Ansätze (D19, D20, D21), welche jedoch keine Echtzeitgarantien liefern, sondern sich auf eine faire Ressourcenverteilung bzw. auf eine Optimierung des Gesamtdurchsatzes konzentrieren. Außerdem werden dort keine Systeme behandelt, bei denen die Ressourcen verteilt vorhanden sind.
  • Die Erfindung ermöglicht eine Integration der oben beschriebenen Mechanismen durch Verwendung eines zentralen Ressourcen-Managers.
  • In 1 ist die prinzipielle Architektur eines Mehrprozessor-Computersystems, welches die Erfindung beinhaltet, dargestellt. Dieses enthält im Einzelnen mehrere Prozessoren 102, welche jeweils private Cache-Speicher enthalten können, mehrere gemeinsam genutzte Cache-Tiles 103, welche jeweils einem Prozessor 102 räumlich zugeordnet sein können, einen zentralen RM 101, eine oder mehrere Datentransfereinheiten (DTE) 105, einen oder mehrere Hauptspeichercontroller 106 zur Anbindung des Hauptspeichers, welche über mehrere physikalisch getrennte Speichercontroller realisiert sein können, eine oder mehrere Ein-/Ausgabe-Schnittstellen 107, optional einen oder mehrere Hardwarebeschleuniger 108 gleicher oder unterschiedlicher Art, sowie ein gemeinsam genutztes Kommunikationsmedium 104, an das alle Komponenten 101, 102, 103, 105, 106, 107 und 108 angebunden sein können.
  • Eine konkrete Ausprägung einer solchen Architektur kann z. B. 64 Prozessoren mit privaten Level-1-Caches, einen auf 64 Teile verteilten Level-2-Cache, 2 Speichercontroller, 2 I/O-Controller und einen RM enthalten, welche über ein 8 × 8 Mesh-Netzwerk verbunden sind. Der verteilte Cache unterstützt Cache-Locking sowie Cache-Partitionierung. Die Speichercontroller implementieren eine prioritätsgesteuerte Ablaufplanung mit zwei Prioritätsklassen LOW und NORMAL, mit einer einstellbaren Datenratenbegrenzung (Traffic-Shaping) für die NORMAL-Klasse. Das Netzwerk unterstützt drei Prioritäten LOW, NORMAL und HIGH, welche mittels Priorisierung und verteilter Datenratenbegrenzung (Traffic-Shaping) eine Isolierung ermöglichen. Zudem erlaubt das Netzwerk mittels Address-Mapping die flexible Zuordnung von Speicher- und Netzwerkadressen.
  • Charakteristisch für jede Ausprägung eines Computersystems im Sinne der Erfindung sind Mechanismen zur Verwaltung bzw. Reservierung aller gemeinsam genutzten Ressourcen, also z. B. Speicher bzw. Cache, Kommunikationsmedium, DTE, Speichercontroller und Ein-/Ausgabe-Einheit. Auf diese Infrastruktur setzt in jeder Ausprägung ein Ressourcen-Manager auf.
  • In der Grundkonfiguration stellt dieses System ein symmetrisches Mehrprozessorsystem (SMP) mit uneinheitlichem Cache-Zugriff (non-uniform cache access, NUCA) und ggf. uneinheitlichem Speicherzugriff (non-uniform memory access, NUMA) dar. Hierbei können alle Prozessoren 102 unter Verwendung eines gemeinsamen Adressraumes über Cache-Speicher 103 auf den Hauptspeicher 106 zugreifen.
  • Applikationen können nun beim RM bestimmte Dienste anfragen. Diese Anfragen können in Form von virtuellen Komponenten mit definiertem Zeitverhalten gestellt werden. Hierbei übernimmt der RM die Konfiguration sämtlicher Komponenten, wie in 3 dargestellt: Anwendungen 403 (welche auf einem oder mehreren Prozessoren 102 ausgeführt werden) stellen Reservierungsanfragen 401. Der RM bearbeitet eine solche Reservierungsanfrage, indem er geeignete Ressourcen bzw. deren Konfiguration auswählt. Diese ausgewählte Konfiguration wird dann über Konfigurationsnachrichten 402 und/oder Konfigurationsregister in den einzelnen beteiligten Komponenten 103, 104, 105, 106, 107 und 108 eingestellt.
  • Vorteilhafte Arten von Reservierungsanfragen sind im Folgenden aufgeführt und erläutert.
  • Reservierung eines virtuellen eingebetteten Systems
  • Hierbei fragt die Anwendung 403 ein virtuelles eingebettetes System an, wie in 2 beispielhaft dargestellt, mit virtuellen Prozessoren 302, SPMs 303, Caches 103, virtuellen Datentransfereinheiten (DTE) 305 und Punkt-zu-Punkt-Verbindungen 304 sowie ggf. Ein-/Ausgabeeinheiten 107 und Hardware-Beschleunigern 108, jeweils mit gewünschten Mindestanforderungen und definiertem Zeitverhalten. In einer solchen Anfrage übermittelt die anfragende Anwendung also eine komplette Beschreibung eines virtuellen Systems inklusive dem gewünschten Zeitverhalten. Diese Beschreibung umfasst virtuelle Prozessoren 302 und/oder Hardwarebeschleuniger 108 mit einer definierten Ausführungsrate, virtuelle softwareverwaltete Speicher 303 und/oder Caches 103 und/oder Hauptspeicher 106 mit definierter Kapazität, Zugriffszeit und -bandbreite, virtuelle DTE 305 sowie virtuelle Punkt-zu-Punkt-Kommunikationsverbindungen 304 zwischen den virtuellen und realen Komponenten mit definierten Maximallatenzen und Mindestdatenraten.
  • Jede Anfrage 401 durchlauft im RM mehrere Schritte gemäß 4: Zunächst wird im Schritt 501 eine Konfiguration bzw. eine entsprechende Konfigurationsänderung erstellt. Jede Konfigurationsänderung prüft der RM im Schritt 502 zunächst auf ihre Durchführbarkeit. Hierzu liegt eine Systembeschreibung (System-Modell) in Form einer geeigneten Datenstruktur vor, welche die vorhandenen Systemkomponenten, deren Kapazität, aktuelle Auslastung bzw. Konfiguration und Anbindung im System enthält. Anhand dieser Beschreibung kann für eine zu einer Anfrage passenden Systemkonfiguration ermittelt werden, ob diese mit den aktuell verfügbaren Ressourcen erfüllbar ist. Ist dies nicht der Fall, können gemäß Schritt 504 ggf. alternative Konfigurationen probiert werden, indem z. B. eine andere Zuordnung von virtuellen SPMs zu Cache-Teilen gewählt wird. Kann so eine erfüllbare Konfiguration gefunden werden, so wird diese im Schritt 503 vom RM durchgeführt. Anhand der Systembeschreibung kann der RM zudem im Schritt 501 eine Optimierung durchführen, bevor eine Konfigurationsänderung im Schritt 503 erfolgt. So lassen sich beispielsweise durch geeignete Auswahl der Prozessoren und/oder Cache-Teile die benötigten Kommunikationsressourcen minimieren. Alternativ kann eine Optimierung der Leistungsaufnahme oder der Performance von Hintergrundapplikationen durchgeführt werden.
  • Reservierungsanfragen können mit einer Priorität versehen werden. Stellt der RM bei einer Anfrage mit einer bestimmten Priorität im Schritt 505 fest, dass diese auf Grund von früheren Anfragen mit geringerer Priorität nicht erfüllt werden kann, so kann der RM der bzw. den Anwendungen mit niedrigerer Priorität die bereits zugeteilten Ressourcen im Schritt 506 wieder entziehen, wobei eine höhere Instanz wie das Betriebssystem hinzugezogen werden kann, um den Entzug der Reservierung auf Anwendungsseite abzuwickeln.
  • Ist eine Anfrage auf Grund der verfügbaren Ressourcen nicht erfüllbar und existiert auch keine erfüllbare alternative Konfiguration, teilt der RM dies der anfragenden Anwendung im Schritt 507 mit. Diese kann daraufhin gemäß dem Pfad 508 eine alternative Anfrage stellen, welche weniger Ressourcen einer bestimmten Klasse bzw. weniger enge Zeitanforderungen enthält. Hierzu kann die Anwendung beim RM den Grund der Ablehnung einer Anfrage erfragen.
  • Um nach Beendigung einer Anwendung bzw. bei höher priorisierten Anfragen reservierte Ressourcen wieder freizugeben, protokolliert der RM jede durchgeführte Konfigurationsänderung zusammen mit einem Verweis auf die Anfrage bzw. Anwendung, welche diese Konfigurationsänderung veranlasst hat.
  • Die Auswahl einer Konfiguration erfolgt anhand eines System-Modells und stellt ein mehrdimensionales Optimierungsproblem dar. Eine effiziente Lösung kann daher in mehreren Schritten erfolgen. So kann der RM zunächst freie Prozessoren, Cache-Speicher, Hardwarebeschleuniger, Datentransfereinheiten und Speichercontroller auswählen und konfigurieren, bevor in einem zweiten Schritt die dazwischenliegenden Kommunikationsressourcen entsprechend den Latenz- und Bandbreitenanforderungen konfiguriert werden.
  • Die Reservierung der ausgewählten Ressourcen erfolgt durch den Ressourcen-Manager, wie in 5 dargestellt. Dieser greift, ggf. über ein Kommunikationsmedium, auf entsprechende Konfigurationsschnittstellen der beteiligten Ressourcen zu, wie nachfolgend beispielhaft beschrieben:
    • – Um die reservierten Speicher in den Adressraum der beteiligten Komponenten (Prozessoren und Hardwarebeschleuniger) einzubinden, wird das Address-Mapping dieser Komponenten bzw. der betroffenen Netzwerk-Adapter entsprechend eingestellt.
    • – Cache-Speicher wird über Cachepartitionierungsregister der beteiligten Caches reserviert. Für die Reservierung von Cache-Teilen als SPM werden diese gesperrt. Um eine cachezeilenweise Sperrung zu beschleunigen, kann der RM durch eine DTE unterstützt werden, welche die entsprechenden Anfragen an die Caches im Hintergrund generiert. Hierbei verwendet die DTE das zuvor eingestellte Address-Mapping. Die DTE meldet die Fertigstellung der Sperrung an den RM.
    • – Prozessoren und Hardwarebeschleuniger werden über das Scheduling der Laufzeitumgebung und/oder entsprechende Konfigurationsregister reserviert.
    • – Bandbreiten und Latenzen von Hauptspeicherzugriffen werden z. B. über entsprechende Konfigurationsregister in den Hauptspeichercontrollern gesteuert.
    • – Der RM protokolliert die durchgeführten Konfigurationsänderungen zusammen mit der Reservierungsanfrage bzw. einer Referenz auf die reservierende Anwendung.
    • – Sobald alle Ressourcen reserviert wurden, teilt der RM dies der Anwendung bzw. der Laufzeitumgebung mit, woraufhin die Anwendung das reservierte virtuelle System nutzen kann.
  • Reservierung eines virtuellen, softwareverwalteten Speichers
  • Hierbei fragt die Anwendung 403 einen virtuellen, softwareverwalteten Speicher mit konfigurierbarer Größe, maximaler Zugriffslatenz und minimaler Zugriffsdatenrate an.
  • Eine solche Anfrage erfüllt der RM 101, indem er entsprechend große Teile des verteilten Cache-Speichers 103 auswählt und sperrt (lockt). Hierzu kann wieder eine DTE verwendet werden, um die Sperrung im Hintergrund durchzuführen. Anschließend konfiguriert der RM das Kommunikationsmedium 104 so, dass die Zugriffslatenz und -datenrate erfüllt werden.
  • 6 zeigt das Verfahren im Detail anhand eines Beispiels: Die Anwendung 403 stellt eine Anfrage an den Ressourcen-Manager 101 zur Bereitstellung eines virtuellen SPM, welche geforderte Parameter, nämlich Kapazität, Zugriffslatenz und Zugriffsbandbreite, für zu reservierenden Cache-Speicher enthalten. Zur Erfüllung einer solchen Anfrage wählt der RM einen oder mehrere der verteilen Cache-Teile 103 aus und reserviert (bzw. lockt) entsprechend große Teile, hier ohne Beteiligung der DTE dargestellt. Zusätzlich konfiguriert der RM die Prioritäten und Bandbreitenbegrenzer im Kommunikationsmedium 104 in der Art um, dass die gewünschten Zugriffslatenz und -bandbreite zwischen den Prozessoren der anfragenden Anwendung und den reservierten Cache-Speichern gewährleistet sind. In diesem Schritt wird auch die Adressumsetzung, welche im Kommunikationsmedium implementiert sein kann, so eingestellt, dass die reservierten Cache-Speicher in den Adressraum der anfragenden Anwendung eingebunden werden.
  • Durchführung eines Datentransfers im Hintergrund
  • Hierbei fragt die Anwendung 403 einen Datentransfer im Hintergrund mit konfigurierbaren Quell- und Zieladressmustern sowie einer spätesten Fertigstellungszeit an. Eine solche Anfrage erfüllt der RM 101, indem er aus Quell- und Zieladressmustern die Quelle, das Ziel sowie das zu transportierende Datenvolumen bestimmt. Aus dem Datenvolumen und der spätesten Fertigstellungszeit ermittelt der RM die nötige durchschnittliche Datenrate und konfiguriert anschließend das Kommunikationsmedium 104 zwischen Quelle und Ziel entsprechend. Der RM wählt nun eine passende DTE 105 aus und konfiguriert diese so, dass der gewünschte Datentransfer durchgeführt wird.
  • Literaturliste
    • D1 „Efficient Utilization of Scratch-Pad Memory in Embedded Processor Application”, Panda, P. R. and Dutt, N. D. and Nicolau, A., Proceedings of the 1997 European conference on Design and Test, 1997, S. 7–11
    • D2 EP 000000999500 A1 D3 „Data cache locking for higher program predictability”, Vera, X. and Lisper, B. and Xue, J., Proceedings of the 2003 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, 2003, S. 272–282
    • D4 EP 000000459233 A3
    • D5 EP 000001363193 B1
    • D6 „Achieving Predictable Performance with On-Chip Shared L2 Caches for Manycore-Based Real-Time Systems”, Cho, S. and Jin, L. and Lee, K., 13th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, 2007, S. 3–11
    • D7 Lei Jin, Hyunjin Lee, Sangyeun Cho (University of Pittsburgh): „A flexible data to L2 cache mapping approach for future multicore processors”, Proceedings of the 2006 workshop on Memory system performance and correctness
    • D8 EP 000000486145 A2
    • D9 „Predator: a predictable SDRAM memory controller”, Akesson, B. and Goossens, K. and Ringhofer, M., Proceedings of the 5th IEEE/ACM international conference on Hardware/software codesign and system synthesis, 2007, S. 251–256
    • D10 „Traffic shaping for an FPGA based SDRAM controller with complex QoS requirements”, Heithecker, S. and Ernst, R., Design Automation Conference; 2005. Proceedings. 42nd, 2005, S. 575–578
    • D11 E. Bolotin, I. Cidon, R. Ginosar, and A. Kolodny, ”QNoC: QoS architecture and design process for network on chip,” J. Syst. Archit., vol. 50, no. 2–3, pp. 105–128, 2004.
    • D12 N. Kavaldjiev, G. Smit, P. Jansen, and P. Wolkotte, ”A Virtual Channel Network-on-Chip for GT and BE traffic,” IEEE ISVLSI.
    • D13 T. Bjerregaard, The MANGO clockless network-on-chip: concepts and implementation. IMM, Danmarks Tekniske Universitet, 2005.
    • D14 K. Goossens, J. Dielissen, and A. Radulescu, ”Æthereal Network on Chip: Concepts, Architectures, and Implementations,” IEEE DESIGN & TEST, pp. 414–421, 2005.
    • D15 T. M. Marescaux, Mapping and management of communication services on MP-SoC platforms. Technische Universiteit Eindhoven, 2007.
    • D16 Wentzlaff, D. and Griffin, P. and Hoffmann, H. and Bao, L. and Edwards, B. and Ramey, C. and Mattina, M. and Miao, C. C. and Brown III, J. F. and Agarwal, A., ”On-Chip Interconnection Architecture of the Tile Processor”, IEEE Micro 5-2007.
    • D17 William J. Dally, Brian Patrick Towles, „Principles and Practices of Interconnection Networks”, S. 239ff., Morgan Kaufman, 2003, ISBN: 978-0122007514
    • D18 Andrew S. Tanenbaum, „Computer Networks, Fourth Edition”, S. 399ff., Prentice Hall PTR, 2002, ISBN: 978-0130661029.
    • D19 R. Iyer et al., „QoS policies and architecture for cache/memory in CMP platforms”, SIGMETRICS '07 Conference Proceedings, 2007.
    • D20 Fei Guo, Yan Solihin, Li Zhao, Ravishankar Iyer, „A Framework for Providing Quality of Service in Chip Multi-Processors”, Proceedings of the 40th Annual IEEE/ACM International Symposium on Microarchitecture, 2007.
    • D21 R. Bitirgen, E. Ipek, J. F. Martinez, „Coordinated Management of Multiple Interacting Resources in Chip Multiprocessors: A Machine Learning Approach”, Proceedings of the 41 st Annual IEEE/ACM International Symposium on Microarchitecture, 2008.

Claims (15)

  1. Mehrprozessor-Computersystem mit wenigstens zwei Mikroprozessoren (102) sowie von den Mikroprozessoren gemeinsam benutzten realen Hardware-Ressourcen (103, 105, 106, 107, 108), wobei die realen Hardware-Ressourcen (103, 105, 106, 107, 108) sowie die Mikroprozessoren (102) an ein gemeinsam genutztes Kommunikationsmedium (104) angebunden sind, wenigstens einem Ressourcen-Manager (101) als separate Hardware-Komponente, wobei der Ressourcen-Manager (101) a) eine von einem Programm (403) gesandte Reservierungsanfrage (401) zur Reservierung einer gewünschten virtuellen Ressource (302, 303, 305) empfängt und verarbeitet, wobei die Reservierungsanfrage (401) wenigstens Art, Kapazität sowie Zugriffslatenz und Zugriffsbandbreite der gewünschten virtuellen Ressource (302, 303, 305) funktional beschreibt, b) eine Zuordnung der virtuellen Ressource (302, 303, 305) zu realen Hardware-Ressourcen (103, 105, 106, 107, 108) vornimmt, c) die reale Hardware-Ressource (103, 105, 106, 107, 108) und das Kommunikationsmedium (104) so einstellt, dass die gewünschte Zugriffslatenz und Zugriffsbandbreite zwischen den Mikroprozessoren (102), auf denen das anfragende Programm (403) ausgeführt wird, und den realen Hardware-Ressourcen (103, 105, 106, 107, 108) gewährleistet sind.
  2. Mehrprozessor-Computersystem nach Anspruch 1, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) zur Zuteilung von mehr als einer realen Hardware-Ressource (103, 105, 106, 107, 108) pro Reservierungsanfrage (401) ausgebildet ist.
  3. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) über ein System-Modell verfügt, das wenigstens die von dem Ressourcen-Manager (101) verwalteten realen Hardware-Ressourcen (103, 105, 106, 107, 108) hinsichtlich Art, Kapazität sowie Zugriffslatenz und Zugriffsbrandbreite beschreibt.
  4. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Ressourcen virtuelle Ressourcen bereitgestellt werden, die virtuelle Scratch-Pad-Memories (303) mit Datentransfereinheiten (305) enthalten.
  5. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die von dem Ressourcen-Manager (101) verwalteten realen Hardware-Ressourcen (103, 105, 106, 107, 108) wenigstens einen Speicher oder Speichercontroller (106), einen Hardware-Beschleuniger (108), einen Cache-Speicher (103), eine Datentransfereinheit (305), und/oder wenigstens eine Ein- und/oder Ausgabeeinheit (107) aufweisen können.
  6. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) Änderungen der Konfiguration von realen Hardware-Ressourcen (103, 105, 106, 107, 108) in Folge bearbeiteter Reservierungsanfragen (401) zusammen mit den zugrunde liegenden Reservierungsanfragen protokolliert.
  7. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) bei Empfang einer Stornierungsmitteilung, z. B. von dem anfragenden Programm oder einer übergeordneten Instanz wie der Laufzeitumgebung oder dem Betriebssystem, die Konfigurationsänderung der entsprechenden Reservierungsanfrage wieder rückgängig macht.
  8. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) eine Reservierungsanfrage (401), die insbesondere aufgrund der jeweiligen Auslastung des Computersystems nicht erfüllbar ist, abweist.
  9. Mehrprozessor-Computersystem nach Anspruch 8, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) im Falle einer Abweisung einer Reservierungsanfrage (401) dem anfragenden Programm (403) die Ursache der Abweisung mitteilt.
  10. Mehrprozessor-Computersystem nach Anspruch 9, dadurch gekennzeichnet, dass das eine Reservierung anfragende Programm (403) im Falle einer Abweisung anhand der ihr mitgeteilten Ursache eine alternative Reservierungsanfrage an den Ressourcen-Manager (101) sendet, die in Bezug auf die mitgeteilte Ursache der Abweisung erfüllbar ist.
  11. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Reservierungsanfrage (403) eine Prioritätsinformation enthält, wobei der Ressourcen-Manager (101) bei Erhalt einer Reservierungsanfrage (403) mit einer bestimmten Priorität bereits erteilte Reservierungen mit geringerer Priorität stornieren kann, z. B. zur Erfüllung einer Reservierungsanfrage mit höherer Priorität, und die Stornierungen den anfragenden Programmen (403) mitteilt.
  12. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) bei der Auswahl der zu reservierenden realen Hardware-Ressourcen (103, 105, 106, 107, 108) eine Optimierung, beispielsweise eine Minimierung der benötigten Kommunikationsmedien (104), durchführt.
  13. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) mit wenigstens einer Datentransfereinheit (105) kommuniziert, die im Hintergrund Daten zwischen Komponenten des Computersystems transportiert.
  14. Mehrprozessor-Computersystem nach wenigstens einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Ressourcen-Manager (101) auf eine programmierbare Datentransfereinheit (105) zugreift, die erweiterte Adressmuster und die Möglichkeit zur Übertragung bestimmter Konfigurationen an einzelne Systemkomponenten im Hintergrund beinhaltet und die bei der Einstellung des Zeitverhaltens unterstützt.
  15. Verfahren, das auf einem Mehrprozessor-Computersystem nach einem der vorhergehenden Ansprüche ausgeführt wird, mit den Schritten: der Ressourcen-Manager (101) empfängt eine von einem Programm (403) gesandte Reservierungsanfrage zur Reservierung einer gewünschten virtuellen Ressource (302, 303, 305) und verarbeitet diese, wobei die Reservierungsanfrage (401) wenigstens Art, Kapazität sowie Zugriffslatenz und Zugriffsbandbreite der gewünschten virtuellen Ressource (302, 303, 305) funktional beschreibt; der Ressourcen-Manager (101) nimmt eine Zuordnung der virtuellen Ressource (302, 303, 305) zu realen Hardware-Ressourcen (103, 105, 106, 107, 108) vor; der Ressourcen-Manager (101) stellt die reale Hardware-Ressource (103, 105, 106, 107, 108) und das Kommunikationsmedium (104) so ein, dass die gewünschte Zugriffslatenz und Zugriffsbandbreite zwischen den Mikroprozessoren (102), auf denen das anfragende Programm (403) ausgeführt wird, und den realen Hardware-Ressourcen (103, 105, 106, 107, 108) gewährleistet sind.
DE102009016742A 2009-04-09 2009-04-09 Mehrprozessor-Computersystem Active DE102009016742B4 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102009016742A DE102009016742B4 (de) 2009-04-09 2009-04-09 Mehrprozessor-Computersystem
US12/757,411 US8515797B2 (en) 2009-04-09 2010-04-09 Method for operating a multiprocessor computer system
US13/903,320 US9268618B2 (en) 2009-04-09 2013-05-28 Method for operating a multiprocessor computer system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200910061066 DE102009061066A1 (de) 2009-04-09 2009-04-09 Kommunikationsmedium für ein Mehrprozessor-Computersystem
DE102009016742A DE102009016742B4 (de) 2009-04-09 2009-04-09 Mehrprozessor-Computersystem

Publications (2)

Publication Number Publication Date
DE102009016742A1 DE102009016742A1 (de) 2010-10-21
DE102009016742B4 true DE102009016742B4 (de) 2011-03-10

Family

ID=42750912

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009016742A Active DE102009016742B4 (de) 2009-04-09 2009-04-09 Mehrprozessor-Computersystem

Country Status (2)

Country Link
US (2) US8515797B2 (de)
DE (1) DE102009016742B4 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017109703B3 (de) 2017-05-05 2018-06-28 Technische Universität Braunschweig Verfahren zur Koordination des Zugriffs auf eine Ressource eines verteilten Computersystems, Computersystem und Computerprogramm
DE102017214068A1 (de) 2017-08-11 2019-02-14 Ttz Embedded Systems Innovationsgesellschaft Technische Universität Braunschweig Mbh Verfahren, Vorrichtung und Computerprogramm zur dynamischen Ressourcenzuweisung in einem Mehrprozessor-Computersystem
DE102017012270A1 (de) 2017-08-11 2019-06-19 Ttz Embedded Systems Innovationsgesellschaft Technische Universität Braunschweig Mbh erfahren, Vorrichtung und Computerprogramm zur dynamischen Ressourcenzuweisung in einem Mehrprozessor-Computersystem
US20230079993A1 (en) * 2020-02-11 2023-03-16 Telefonaktiebolaget Lm Ericsson (Publ) Creating services in a virtualised network environment

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100948597B1 (ko) * 2007-12-17 2010-03-24 한국전자통신연구원 다중 복호기 시스템에서의 리소스 공유 스케줄 제어 장치및 그 장치에서의 리소스 공유 스케줄 제어 방법
US9317329B2 (en) 2010-11-15 2016-04-19 Qualcomm Incorporated Arbitrating resource acquisition for applications of a multi-processor mobile communications device
US20120209413A1 (en) 2011-02-14 2012-08-16 Microsoft Corporation Background Audio on Mobile Devices
US8918791B1 (en) 2011-03-10 2014-12-23 Applied Micro Circuits Corporation Method and system for queuing a request by a processor to access a shared resource and granting access in accordance with an embedded lock ID
US20120233315A1 (en) * 2011-03-11 2012-09-13 Hoffman Jason A Systems and methods for sizing resources in a cloud-based environment
US9143467B2 (en) 2011-10-25 2015-09-22 Mellanox Technologies Ltd. Network interface controller with circular receive buffer
US8751701B2 (en) * 2011-12-26 2014-06-10 Mellanox Technologies Ltd. Host channel adapter with pattern-type DMA
US9515899B2 (en) * 2012-12-19 2016-12-06 Veritas Technologies Llc Providing optimized quality of service to prioritized virtual machines and applications based on quality of shared resources
WO2014130037A1 (en) * 2013-02-21 2014-08-28 Empire Technology Development, Llc One-cacheable multi-core architecture
US8677359B1 (en) 2013-03-14 2014-03-18 Joyent, Inc. Compute-centric object stores and methods of use
US8775485B1 (en) 2013-03-15 2014-07-08 Joyent, Inc. Object store management operations within compute-centric object stores
US9652425B2 (en) * 2013-06-28 2017-05-16 Intel Corporation Method, apparatus and system for a source-synchronous circuit-switched network on a chip (NOC)
WO2016168202A1 (en) * 2015-04-14 2016-10-20 Sendyne Corporation Model numerical solver for system control
US11979340B2 (en) 2017-02-12 2024-05-07 Mellanox Technologies, Ltd. Direct data placement
US10516710B2 (en) 2017-02-12 2019-12-24 Mellanox Technologies, Ltd. Direct packet placement
US10210125B2 (en) 2017-03-16 2019-02-19 Mellanox Technologies, Ltd. Receive queue with stride-based data scattering
JP6821509B2 (ja) * 2017-05-25 2021-01-27 ルネサスエレクトロニクス株式会社 情報処理装置並びにその制御方法及び制御プログラム
US11252464B2 (en) 2017-06-14 2022-02-15 Mellanox Technologies, Ltd. Regrouping of video data in host memory
US10367750B2 (en) 2017-06-15 2019-07-30 Mellanox Technologies, Ltd. Transmission and reception of raw video using scalable frame rate
CN107528976B (zh) 2017-08-31 2020-03-24 Oppo广东移动通信有限公司 资源配置方法及相关产品
CN109992398B (zh) * 2017-12-29 2021-06-25 Oppo广东移动通信有限公司 资源管理方法、装置、移动终端及计算机可读存储介质
CN115136123A (zh) * 2019-11-26 2022-09-30 米西克有限公司 用于集成电路架构内的自动化数据流和数据处理的瓦片子***和方法
CN112130848B (zh) * 2020-09-24 2022-06-14 中国科学院计算技术研究所 一种面向便笺式存储器的带宽感知循环分块优化方法、编译***、设备及存储介质
US20230037780A1 (en) * 2021-07-21 2023-02-09 Azimuth Technology, Llc Computing device with one or more hardware accelerators directly coupled with cluster of processors
US20240012773A1 (en) * 2022-07-06 2024-01-11 Mellanox Technologies, Ltd. Patterned Direct Memory Access (DMA)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978363A (en) * 1996-10-18 1999-11-02 Telogy Networks, Inc. System and method for multi-dimensional resource scheduling
DE19983709B4 (de) * 1998-11-09 2007-02-22 Intel Corporation, Santa Clara Einplanung von Ressourcenanforderungen in einem Computersystem
DE102006019839A1 (de) * 2005-08-24 2007-03-15 Agilent Technologies, Inc. (n.d.Ges.d.Staates Delaware), Palo Alto Zeitbewusste Systeme

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0459233A3 (en) 1990-05-29 1992-04-08 National Semiconductor Corporation Selectively locking memory locations within a microprocessor's on-chip cache
US5182800A (en) 1990-11-16 1993-01-26 International Business Machines Corporation Direct memory access controller with adaptive pipelining and bus control features
US6282561B1 (en) * 1995-12-07 2001-08-28 Microsoft Corporation Method and system for resource management with independent real-time applications on a common set of machines
US5978770A (en) * 1997-04-24 1999-11-02 Visible Interactive Corporation Assigning and managing patron reservations for distributed services using wireless personal communication devices
EP0999500A1 (de) 1998-11-06 2000-05-10 Lucent Technologies Inc. Durch ein Anwendungsprogramm wiederkonfigurierbarer aufgeteilter Cache-Speicher
US7209439B2 (en) * 2001-03-20 2007-04-24 Mci, Llc Pool-based resource management in a data network
EP1363193B1 (de) 2002-05-15 2006-05-03 Broadcom Corporation Programmierbarer Cache für die Partitionierung von lokalen und entfernten Cacheblöcken
US7353321B2 (en) * 2003-01-13 2008-04-01 Sierra Logic Integrated-circuit implementation of a storage-shelf router and a path controller card for combined use in high-availability mass-storage-device shelves that may be incorporated within disk arrays
US7694082B2 (en) * 2005-07-29 2010-04-06 International Business Machines Corporation Computer program and method for managing resources in a distributed storage system
CN100463422C (zh) * 2006-09-08 2009-02-18 中山大学 一种链路、路径、网络可用带宽测量方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5978363A (en) * 1996-10-18 1999-11-02 Telogy Networks, Inc. System and method for multi-dimensional resource scheduling
DE19983709B4 (de) * 1998-11-09 2007-02-22 Intel Corporation, Santa Clara Einplanung von Ressourcenanforderungen in einem Computersystem
DE102006019839A1 (de) * 2005-08-24 2007-03-15 Agilent Technologies, Inc. (n.d.Ges.d.Staates Delaware), Palo Alto Zeitbewusste Systeme

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Ray, S. et al.: A reconfigurable bus structure for multiprocessors with bandwidth reuse. In: Journal of Systems Architecture, Vol. 45, No. 11, May 1999, pp. 847-862, Abstract *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017109703B3 (de) 2017-05-05 2018-06-28 Technische Universität Braunschweig Verfahren zur Koordination des Zugriffs auf eine Ressource eines verteilten Computersystems, Computersystem und Computerprogramm
WO2018202446A1 (de) 2017-05-05 2018-11-08 Technische Universität Braunschweig Verfahren zur koordination des zugriffs auf eine ressource eines verteilten computersystems, computersystem und computerprogrramm
US10893001B2 (en) 2017-05-05 2021-01-12 Technische Universitat Braunschweig Method for coordinating access to a resource of a distributed computer system, computer system and computer program
DE102017214068A1 (de) 2017-08-11 2019-02-14 Ttz Embedded Systems Innovationsgesellschaft Technische Universität Braunschweig Mbh Verfahren, Vorrichtung und Computerprogramm zur dynamischen Ressourcenzuweisung in einem Mehrprozessor-Computersystem
WO2019030388A1 (de) 2017-08-11 2019-02-14 Ttz Embedded Systems Innovationsgesellschaft Technische Universität Braunschweig Mbh Verfahren, vorrichtung und computerprogramm zur dynamischen ressourcenzuweisung in einem mehrprozessor-computersystem
DE102017012270A1 (de) 2017-08-11 2019-06-19 Ttz Embedded Systems Innovationsgesellschaft Technische Universität Braunschweig Mbh erfahren, Vorrichtung und Computerprogramm zur dynamischen Ressourcenzuweisung in einem Mehrprozessor-Computersystem
DE102017214068B4 (de) 2017-08-11 2021-12-09 Ttz Embedded Systems Innovationsgesellschaft Technische Universität Braunschweig Mbh Verfahren, Vorrichtung und Computerprogramm zur dynamischen Ressourcenzuweisung in einem Mehrprozessor-Computersystem
US20230079993A1 (en) * 2020-02-11 2023-03-16 Telefonaktiebolaget Lm Ericsson (Publ) Creating services in a virtualised network environment

Also Published As

Publication number Publication date
US20130339982A1 (en) 2013-12-19
US9268618B2 (en) 2016-02-23
US8515797B2 (en) 2013-08-20
US20100262973A1 (en) 2010-10-14
DE102009016742A1 (de) 2010-10-21

Similar Documents

Publication Publication Date Title
DE102009016742B4 (de) Mehrprozessor-Computersystem
DE102016221811B4 (de) Zuordnung von Ressourcen mit mehrschichtigem Speicher
DE112013000395B4 (de) Vorrichtung, verfahren und computerlesbarer speicher zur richtliniendurchsetzung in rechenumgebung
DE102004012056B4 (de) System und Verfahren zum Überwachen von Ressourcenausnutzung und Anwendungsleistungsfähigkeit
DE102015105884B4 (de) Rechenknoten und Verfahren zur Migration einer virtuellen Maschine, Rechenzentrummanager zur Migration virtueller Maschinen, Maschinenlesbares Speichermedium und Rechenvorrichtungen
DE69716663T2 (de) Prozesszuweisung in einem Mehrrechnersystem
DE69930855T2 (de) Verfahren und vorrichtung zur durchführung einer deterministischen speicherzuordnungsantwort in einem computer-system
DE102009032581B4 (de) Management der Zeitsteuerung eines Protokollstapels
DE60016283T2 (de) Arbeitsbelastungsverwaltung in einer rechnerumgebung
DE69533680T2 (de) Verfahren und Vorrichtung zur dynamischen Bestimmung und Zuteilung von Zugriffsguoten für ein gemeinsames Betriebsmittel
DE102012219907B4 (de) Erhöhen der Speicherkapazität in Systemen mit eingeschränkter elektrischer Leistungsaufnahme
DE102006019839A1 (de) Zeitbewusste Systeme
DE102005029852B4 (de) Steueranordnung zum Freigeben einer oder mehrerer virtueller Speicherseiten nach Beendigung eines Programms in einem Multiprozessorcomputersystem
DE112013003733T5 (de) Adaptive Paketumlenkung, um angemessene, kostengünstige und/oder Energie-effiziente Dienstgüte im Netzwerk auf Chipvorrichtungen zu erreichen
DE102006032832A1 (de) Netzwerksystem und Verfahren zur Steuerung verteilter Speicher
DE102005030663A1 (de) System und Verfahren zum Betreiben von Lastausgleichselementen für Mehrfachinstanzanwendungen
DE102004028807A1 (de) Computersystem, Steuervorrichtung, Speichersystem und Computergerät
DE112020004661T5 (de) Ermitteln einer optimalen Anzahl von Threads pro Kern in einem Mehrkern-Prozessorkomplex
DE112007002201T5 (de) Quality-of-Service-Implementierung für Plattformressourcen
DE102016013577A1 (de) Systeme und Verfahren zum adaptiven Partitionieren in verteilten Cache-Speichern
DE69619531T2 (de) Dynamischer lastausgleich
DE102014019531A1 (de) Verfahren zum Betrieb einer Steuerungskomponente für ein Luftfahrzeug sowie Steuerungskomponente
DE102017214068A1 (de) Verfahren, Vorrichtung und Computerprogramm zur dynamischen Ressourcenzuweisung in einem Mehrprozessor-Computersystem
DE112021005586T5 (de) Automatisches skalieren einer abfrage-steuerungsroutine für arbeitslasten im bereich big data auf unternehmensebene
DE112016004367T5 (de) Technologien für automatische Prozessorkern-Zuordnungsverwaltung und -Kommunikation unterVerwendung direkter Datenplatzierung in private Zwischenspeicher

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
AH Division in

Ref document number: 102009061066

Country of ref document: DE

Kind code of ref document: P

R020 Patent grant now final

Effective date: 20110702

R082 Change of representative

Representative=s name: GRAMM, LINS & PARTNER PATENT- UND RECHTSANWAEL, DE

R081 Change of applicant/patentee

Owner name: INNOVATIONSGESELLSCHAFT TECHNISCHE UNIVERSITAE, DE

Free format text: FORMER OWNER: TECHNISCHE UNIVERSITAET BRAUNSCHWEIG CAROLO-WILHELMINA, 38106 BRAUNSCHWEIG, DE

R082 Change of representative

Representative=s name: GRAMM, LINS & PARTNER PATENT- UND RECHTSANWAEL, DE

R082 Change of representative

Representative=s name: MEISSNER BOLTE PATENTANWAELTE RECHTSANWAELTE P, DE