DE102021127324A1 - Planung von aufträgen auf grafischen verarbeitungseinheiten - Google Patents

Planung von aufträgen auf grafischen verarbeitungseinheiten Download PDF

Info

Publication number
DE102021127324A1
DE102021127324A1 DE102021127324.2A DE102021127324A DE102021127324A1 DE 102021127324 A1 DE102021127324 A1 DE 102021127324A1 DE 102021127324 A DE102021127324 A DE 102021127324A DE 102021127324 A1 DE102021127324 A1 DE 102021127324A1
Authority
DE
Germany
Prior art keywords
gpus
job
existing
vgpus
jobs
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.)
Pending
Application number
DE102021127324.2A
Other languages
English (en)
Inventor
Diman ZAD TOOTAGHAJ
Junguk Cho
Puneet Sharma
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.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
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 Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102021127324A1 publication Critical patent/DE102021127324A1/de
Pending legal-status Critical Current

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/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/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00General purpose image data processing
    • G06T1/20Processor architectures; Processor configuration, e.g. pipelining
    • 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/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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/5061Partitioning or combining of resources
    • G06F9/5072Grid computing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Beispielimplementierungen beziehen sich auf die Planung von Aufträgen für eine Vielzahl von Grafikverarbeitungseinheiten (GPUs), die eine gleichzeitige Verarbeitung durch eine Vielzahl von virtuellen GPUs ermöglichen. Gemäß einem Beispiel empfängt ein Computersystem mit einer oder mehreren GPUs eine Anforderung zur Planung eines neuen Auftrags, der von dem Computersystem ausgeführt werden soll. Der neue Auftrag wird einer oder mehreren vGPUs zugewiesen. Die Zuweisungen bestehender Aufträge werden für eine oder mehrere vGPUs aktualisiert. Die Betriebskosten für den Betrieb der einen oder mehreren GPUs und die Migrationskosten für die Zuweisung des neuen Auftrags werden minimiert und die Zuweisungen der bestehenden Aufträge auf der einen oder den mehreren vGPUs werden aktualisiert. Der neue Auftrag und die bestehenden Aufträge werden von dem einen oder den mehreren Grafikprozessoren im Rechensystem verarbeitet.

Description

  • HINTERGRUND
  • Einige Computersysteme verwenden Grafikprozessoren (GPUs), um Berechnungen für Anwendungen durchzuführen. Bei einigen Systemen können mehrere Anwendungen gleichzeitig auf einem einzigen Grafikprozessor ausgeführt werden.
  • Figurenliste
  • Die hier beschriebenen Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen sich gleiche Bezugsziffern auf ähnliche Elemente beziehen.
    • 1 ist eine schematische Darstellung eines Computersystems gemäß einigen Ausführungsformen.
    • 2 ist ein Diagramm einer beispielhaften Anordnung von Jobs und GPUs gemäß einigen Ausführungsformen.
    • 3 ist ein Flussdiagramm der GPU-Scheduler-Verarbeitung gemäß einigen Ausführungsbeispielen.
    • 4 ist ein Blockdiagramm eines Verarbeitungsknotens eines verteilten Computersystems in Übereinstimmung mit einer Ausführungsform.
    • 5 ist ein Blockdiagramm, das einen Verarbeitungsknoten eines verteilten Rechnersystems gemäß einer Ausführungsform zeigt.
  • DETAILLIERTE BESCHREIBUNG
  • Bei einigen GPUs kann nur ein Prozess (z. B. ein Anwendungsprogramm) die GPU zu einem bestimmten Zeitpunkt nutzen (z. B. durch Multiplexing-Techniken). Da die GPU-Rechenkapazität in der Regel von einer einzigen Anwendung nicht voll ausgeschöpft wird, kann dies dazu führen, dass die GPU-Ressourcen nicht voll genutzt werden. Einige GPUs umgehen dieses Problem, indem sie die gleichzeitige Verarbeitung mehrerer Prozesse auf derselben GPU ermöglichen. Dies kann zu besseren Leistungsvorteilen führen. Einige Container-Plattformen unterstützen jedoch in der Regel nur ein Modell der exklusiven GPU-Zuweisung an einen Container oder einen Zeitmultiplex-Ansatz für die gemeinsame Nutzung von GPUs. Dieser Ansatz führt zu einer ineffizienten gemeinsamen Nutzung von Ressourcen und Leistungseinbußen und berücksichtigt nicht die effiziente gemeinsame Nutzung von GPUs bei der Planung von Anwendungen, die GPU-Ressourcen benötigen. Da die bestehenden GPU-Planungsansätze entweder keine gemeinsame Nutzung von GPUs zulassen oder ein einfaches „Wer zuerst kommt, mahlt zuerst“-Verfahren verwenden, sind bessere Techniken für die GPU-Planung erforderlich.
  • Die hier beschriebene Technologie umfasst einen GPU-Planungsprozess, der Aufträge an virtuelle GPUs (vGPUs) von GPUs in einem Rechensystem zuweist und dabei die GPU-Betriebskosten und die Kosten für die Auftragsmigration minimiert. Der GPU-Planungsprozess aktualisiert die Zuweisungen von Aufträgen an vGPUs (z. B. was möglicherweise zu einer Migration eines oder mehrerer Aufträge von einer physischen GPU zu einer anderen physischen GPU führt), wenn eine neue Auftragsanforderung eingeht oder wenn ein bestehender Auftrag abgeschlossen wird. Die Technologie funktioniert auf bestehenden Container-Plattformen und kann so konfiguriert werden, dass je nach gewähltem Anwendungsfall den Migrationskosten oder den Betriebskosten Vorrang eingeräumt wird. In einer Implementierung wird der GPU-Planungsprozess als ein ganzzahliges lineares Optimierungsproblem modelliert, das in polynomialer Zeit optimal gelöst werden kann.
  • In der vorliegenden technischen Beschreibung werden zahlreiche spezifische Details aufgeführt, um ein umfassendes Verständnis der Ausführungsbeispiele zu ermöglichen. Einem Fachmann wird jedoch klar sein, dass die hier beschriebenen Ausführungsformen auch ohne einige dieser spezifischen Details ausgeführt werden können. In anderen Fällen werden bekannte Strukturen und Geräte in Form von Blockdiagrammen dargestellt.
  • Die Begriffe „verbunden“ oder „gekoppelt“ und verwandte Begriffe werden in einem operativen Sinne verwendet und sind nicht unbedingt auf eine direkte Verbindung oder Kopplung beschränkt. So können beispielsweise zwei Geräte direkt oder über ein oder mehrere zwischengeschaltete Medien oder Geräte gekoppelt sein. Ein weiteres Beispiel ist, dass Geräte so gekoppelt sein können, dass Informationen zwischen ihnen ausgetauscht werden können, ohne dass sie eine physische Verbindung miteinander haben. Auf der Grundlage der hierin enthaltenen Offenlegung wird ein Fachmann eine Vielzahl von Möglichkeiten erkennen, wie eine Verbindung oder Kopplung im Sinne der oben genannten Definition besteht.
  • Wenn es in der Spezifikation heißt, dass ein Bauteil oder ein Merkmal „enthalten sein kann“, „kann“, „könnte“ oder „könnte“, muss dieses bestimmte Bauteil oder Merkmal nicht enthalten sein oder das Merkmal aufweisen.
  • Wie in der vorliegenden Beschreibung und in den folgenden Ansprüchen verwendet, schließt die Bedeutung von „a“, „an“ und „die“ den Plural ein, sofern der Kontext nicht eindeutig etwas anderes vorschreibt. Wie in der vorliegenden Beschreibung verwendet, schließt die Bedeutung von „in“ auch „in“ und „am“ ein, sofern der Kontext nicht eindeutig etwas anderes vorschreibt.
  • Die Ausdrücke „in einer Ausführungsform“, „gemäß einer Ausführungsform“ und dergleichen bedeuten im Allgemeinen, dass das bestimmte Merkmal, die Struktur oder die Eigenschaft, die auf den Ausdruck folgt, in mindestens einer Ausführungsform der vorliegenden Offenbarung enthalten ist und in mehr als einer Ausführungsform der vorliegenden Offenbarung enthalten sein kann. Wichtig ist, dass sich solche Ausdrücke nicht unbedingt auf dieselbe Ausführungsform beziehen.
  • Ein „Knoten“ oder „Verarbeitungsknoten“ bezieht sich im Allgemeinen auf ein Computerelement. Bei den Knoten eines verteilten Systems kann es sich um Computersysteme (z. B. Clients, Server oder Peers) in virtueller oder physischer Form, eine oder mehrere Komponenten eines Computersystems, Rechenelemente, Rechenmaschinen, Hardwaregeräte, Softwareeinheiten oder Prozesse oder eine Kombination davon handeln. Nicht einschränkende Beispiele für Knoten umfassen einen Softwareprozess (z. B. einen Client oder einen Server), eine virtuelle Maschine, einen virtuellen Controller eines Speichersoftware-Stacks, einen Speicherserver, eine hyperkonvergente Plattform, eine Datenvirtualisierungsplattform, einen Sensor oder einen Aktor.
  • 1 ist eine schematische Darstellung eines Computersystems 100 gemäß einigen Ausführungsformen. Das Rechensystem 100 stellt einem oder mehreren Benutzern Rechenressourcen zur Verfügung. Das Computersystem 100 kann einen oder mehrere Server, Speichergeräte, Kommunikationsnetze, Netzwerkstrukturen, Verbindungen, Netzwerkschnittstellenkarten, Schalter, Router usw. umfassen. In einer Implementierung befindet sich das Rechensystem 100 in einem Rechenzentrum und ist mit anderen Rechensystemen verbunden. In anderen Ausführungsformen kann das Computersystem 100 eine beliebige andere Art von Rechengerät sein, wie z. B. ein Personal Computer (Desktop, Laptop oder Workstation) oder ein mobiles Gerät. Das Computersystem 100 enthält mindestens eine Anwendung 102 zur Durchführung der Datenverarbeitung. Die Anwendung 102 sendet eine oder mehrere Auftragsanforderung(en) 104 an den Planer 106. Ein Auftrag, wie hier verwendet, ist eine beliebige Datenverarbeitungsaufgabe. Der Planer 106 weist den Auftrag einer Verarbeitungsressource im Computersystem 100 zu, um den Auftrag auszuführen. Bei einer Verarbeitungsressource kann es sich beispielsweise um eine Zentraleinheit (CPU), eine Grafikverarbeitungseinheit (GPU), ein feldprogrammierbares Gate-Array (FPGA), eine anwendungsspezifische Schaltung (ASIC) usw. handeln. In verschiedenen Ausführungsformen kann der Scheduler 106 in einem Betriebssystem (OS) implementiert sein oder als Container-Orchestrierungssystem (z. B. Kubernetes) implementiert sein.
  • Das Rechensystem 100 umfasst einen oder mehrere Grafikprozessoren, wobei der eine oder die mehreren Grafikprozessoren die Möglichkeit der gleichzeitigen Verarbeitung einer Vielzahl von Aufträgen durch eine Vielzahl von vGPUs bieten. In einer Ausführungsform sind die GPUs im Computersystem 100 heterogen (z. B. sind eine oder mehrere GPUs anders als eine oder mehrere andere GPUs). Beispielsweise werden in einer Ausführungsform eine oder mehrere der GPUs von einem ersten GPU-Hersteller und eine oder mehrere GPUs von einem zweiten Hersteller produziert, und das Design der GPUs des ersten Herstellers unterscheidet sich vom Design der GPUs des zweiten Herstellers. In einigen Fällen kann es sich bei den verschiedenen GPUs um unterschiedliche Modelle desselben Herstellers handeln. Die Ausführungsformen ermöglichen eine effiziente Berechnung der Zuweisung von Aufträgen an GPUs, unabhängig von GPU-Hersteller oder Modelltyp.
  • Wenn die Anwendung 102 so programmiert ist, dass eine GPU zur effizienten Durchführung ausgewählter Datenverarbeitungsaufgaben verwendet wird (wie z. B. bestimmte Aufgaben im Zusammenhang mit künstlicher Intelligenz (KI), maschinellem Lernen (ML), Verarbeitung natürlicher Sprache (NLP), maschineller Wahrnehmung (einschließlich Spracherkennung, Gesichtserkennung, Objekterkennung usw.), neuronalen Netzen usw.), sendet die Anwendung 102 eine oder mehrere Auftragsanforderung(en) 104 an den Scheduler 106, und der Scheduler 106 weist den GPU Scheduler 108 an oder arbeitet mit ihm zusammen, um den Auftrag einer GPU zur Durchführung des Auftrags zuzuweisen. Obwohl der GPU-Scheduler 108 in 1 innerhalb des Schedulers 106 dargestellt ist, kann der GPU-Scheduler 108 in anderen Implementierungen neben oder außerhalb des Schedulers 106 implementiert werden.
  • Das Beispielrechnersystem 100 umfasst eine Vielzahl von GPUs, wie GPU 1 110, GPU 2 112, ... GPU N 114, wobei N eine natürliche Zahl ist. In einer Implementierung umfasst eine GPU eine Vielzahl von virtuellen (vGPUs). Eine physische GPU kann in X vGPUs unterteilt werden, wobei X eine natürliche Zahl ist, die konfigurierbar ist. Eine vGPU ermöglicht es mehreren Anwendungen (z. B. containerisierten Anwendungen) im Computersystem 100, eine physische GPU gemeinsam zu nutzen oder einer einzigen Anwendung mehrere GPUs zuzuweisen. Beispielsweise umfasst GPU 1 110 B1 vGPUs 116, wobei B1 eine natürliche Zahl ist, GPU 2 112 umfasst B2 vGPUs 118, wobei B2 eine natürliche Zahl ist, ... GPU N 114 umfasst BN vGPUs 120, wobei BN eine natürliche Zahl ist. In einer Ausführungsform haben B1 , B2 , ... BN den gleichen Wert. In einer anderen Ausführungsform haben einer oder mehrere der Werte B1 , B2, ... BN unterschiedliche Werte. Somit kann sich die Menge der Verarbeitungsressourcen (über eine Gruppe von vGPUs) auf jeder GPU im Rechensystem 102 von anderen GPUs im Rechensystem 100 unterscheiden. Zum Beispiel könnte B1 fünf, B2 zehn und BN acht betragen.
  • Der GPU-Scheduler 108 bestimmt eine optimale Zuweisung von Aufträgen aus den Auftragsanforderungen 104 zu den vGPUs. In einer Ausführungsform bestimmt der GPU-Scheduler 108 jedes Mal, wenn eine neue Auftragsanforderung eingeht, eine neue optimale Zuweisung von Aufträgen an vGPUs, wobei die Anforderungen des neuen Auftrags und die vorherige Zuweisung bestehender Aufträge an vCPUs berücksichtigt werden. Dies kann dazu führen, dass ein oder mehrere bestehende Aufträge von einer physischen GPU auf eine andere physische GPU verlagert werden. In einer anderen Ausführungsform bestimmt der GPU-Scheduler 108 immer dann, wenn ein bestehender Auftrag abgeschlossen ist, eine neue optimale Zuordnung von Aufträgen zu vGPUs, wobei die Anforderungen des abgeschlossenen Auftrags und die Zuordnung bestehender Aufträge zu vGPUs berücksichtigt werden. Dies kann auch dazu führen, dass ein oder mehrere Aufträge von einer physischen GPU auf eine andere physische GPU verlagert werden. Durch die kontinuierliche Neubewertung der optimalen Zuweisung von Aufträgen zu vGPUs im Computersystem 100 verhindert der GPU-Scheduler 108 eine Überbelegung von GPUs mit Aufträgen, eine Fragmentierung der GPU-Ressourcen und eine Unterauslastung der GPU-Ressourcen. Dies führt zu einer Verbesserung der Gesamtleistung des Rechensystems 100.
  • Sobald der GPU-Scheduler 108 eine Lösung für das Problem der optimalen GPU-Zuweisung in Form eines ganzzahligen linearen Programmieroptimierungsproblems auf der Grundlage von Eingangsvariablen formuliert hat, sendet er die Formulierung an den Solver 122. Solver 122 bestimmt eine optimale Lösung für die Formulierung und gibt einen Satz von Ausgabedaten (wie unten beschrieben) an den GPU-Scheduler zurück. Die Ausgabedaten werden vom GPU-Scheduler verwendet, um die optimale Zuweisung von Aufträgen an GPUs im Computersystem 100 zu implementieren (z. B. möglicherweise durch Migration bestehender Aufträge und/oder Zuweisung neuer Aufträge). In einer Ausführungsform ist der Solver 122 in den GPU-Scheduler 108 integriert. In einer anderen Ausführungsform wird der Löser 122 vom Rechensystem 100 ausgeführt, ist aber nicht in den GPU-Scheduler 108 integriert. In einer weiteren Ausführungsform wird der Löser 122 von einem anderen Computersystem als dem Computersystem 100 ausgeführt (z. B. einem anderen Computersystem, auf das der GPU-Scheduler 108 über ein Netzwerk (z. B. das Internet) zugreifen kann). Für den Solver 122 kann jeder geeignete Solver für ganzzahlige lineare Programmierung verwendet werden, z. B. das Gurobi-Optimierungstoolkit (kommerziell erhältlich von Gurobi Optimization, LLC), der CPLEX-Optimierer (kommerziell erhältlich von IBM Corporation) oder das Tool für lineare Programmierung „OR“ (erhältlich als Open-Source-Software von Google) usw.
  • 2 ist ein Diagramm einer Beispielanordnung 200 von Jobs und GPUs gemäß einigen Ausführungsformen. In diesem Beispiel wird ein Computersystem mit N GPUs betrachtet, wobei GPU 1 110 eine Anzahl von B1 vGPUs 116 mit der Bezeichnung vGPU1-1, ... vGPU1-B1 116 hat; GPU 2 112 hat eine Anzahl von B2 vGPUs 118 mit der Bezeichnung vGPU2-1, vGPU2-2, ... vGPU2-B2 118; und GPU N 110 hat BN Anzahl von vGPUs 120, bezeichnet als vGPUN-1, vGPUN-2, vGPUN-3, ... vGPUN-BN 120, was dazu führt, dass das Rechensystem 100 B = (B1 + B2 + ... + BN ) Anzahl von vGPUs hat, die für die Verarbeitung von Aufträgen verfügbar sind. Angenommen, der GPU-Scheduler 108 erhält eine Auftragsanforderung 104, um den Auftrag F 202 für die Verarbeitung durch die GPUs des Computersystems 100 zuzuweisen, und es wird angenommen, dass der Auftrag F L vGPUs benötigt, um den Auftrag F auszuführen, wobei L eine natürliche Zahl ist. Es wird angenommen, dass der Auftrag nicht mehr als einer physischen GPU zugewiesen werden kann. Es wird davon ausgegangen, dass eine bestimmte Aufgabe mehr, gleich oder weniger vGPUs als jede andere Aufgabe erfordern kann. In einem ersten Beispielaufruf des GPU-Schedulers 108 weist der GPU-Scheduler den Auftrag F 202 optimal L verschiedenen vGPUs aus der Menge der vGPUs 116, 118, ... 120 zu, so dass die Migrationskosten und die Betriebskosten für das Rechensystem 102 minimiert werden, wie nachstehend in Bezug auf 3 beschrieben. Dies kann dazu führen, dass einige GPUs ungenutzt sind und abgeschaltet werden. Dies kann dazu führen, dass einige vGPUs ungenutzt sind. Nach der Zuweisung von Auftrag F sind L vGPUs in den physischen GPUs in Gebrauch.
  • Nehmen wir nun an, dass der GPU-Scheduler 108 eine weitere Auftragsanforderung 104 erhält, um den Auftrag G 204 zur Verarbeitung durch die GPUs des Computersystems 100 zuzuweisen, und nehmen wir an, dass der Auftrag G M vGPUs zur Ausführung des Auftrags G benötigt, wobei M eine natürliche Zahl ist. In einem zweiten Beispielaufruf des GPU-Schedulers 108 weist der GPU-Scheduler den Auftrag G 204 optimal M verschiedenen vGPUs aus der Menge der vGPUs 116, 118, ... 120 zu, so dass die Migrationskosten und die Betriebskosten für das Rechensystem 100 minimiert werden, wie nachstehend in Bezug auf 3 beschrieben. Bei dieser Zuweisungsbestimmung werden der vorhandene Auftrag F 202 und die zuvor zugewiesenen L vGPUs berücksichtigt. Dies kann dazu führen, dass einige GPUs ungenutzt sind und ausgeschaltet werden. Dies kann dazu führen, dass einige vGPUs ungenutzt sind. Dies kann dazu führen, dass ein bestehender Auftrag F 202, der von einer zuvor zugewiesenen physischen GPU ausgeführt wird, auf eine andere physische GPU migriert werden muss. Nach der Zuweisung von Auftrag F sind L+M vGPUs in Gebrauch.
  • Nehmen wir nun an, dass der GPU-Scheduler 108 eine Auftragsanforderung 104 erhält, um den Auftrag H 206 zur Verarbeitung durch die GPUs des Computersystems 100 zuzuweisen, und nehmen wir an, dass der Auftrag H P vGPUs zur Ausführung des Auftrags H benötigt, wobei P eine natürliche Zahl ist. Es wird auch angenommen, dass Auftrag F abgeschlossen ist. In einem dritten Beispielaufruf des GPU-Schedulers 108 weist der GPU-Scheduler den Auftrag H 204 optimal P verschiedenen vGPUs aus der Menge der vGPUs 116, 118, ... 120 zu, so dass die Migrationskosten und die Betriebskosten für das Rechensystem 100 minimiert werden, z. B. auf eine Weise, die unten mit Bezug auf 3 beschrieben wird. Diese Zuweisungsbestimmung berücksichtigt den Abschluss des bestehenden Auftrags F 202 und die zuvor zugewiesenen L vGPUs sowie den bestehenden Auftrag G 204 und die zuvor zugewiesenen M vGPUs. Dies kann dazu führen, dass einige GPUs ungenutzt sind und abgeschaltet werden. Dies kann dazu führen, dass einige vGPUs ungenutzt sind. Dies kann dazu führen, dass ein oder mehrere bestehende Aufträge G 204, die von einer zuvor zugewiesenen physischen GPU ausgeführt werden, auf eine andere physische GPU migriert werden, z. B. auf die physische GPU, die zuvor zur Verarbeitung des Auftrags F 202 verwendet wurde. Nach der Zuweisung von Auftrag H 206 und dem Abschluss von Auftrag F 202 sind M+P vGPUs in Gebrauch.
  • Daher führen wiederholte Aufrufe des GPU-Schedulers 108 zur Zuweisung von Aufträgen an die vGPUs, sobald eine neue Auftragsanforderung eingeht oder ein bestehender Auftrag abgeschlossen ist, zu einer optimalen Nutzung der GPUs im Computersystem 100.
  • 3 ist ein Flussdiagramm der GPU-Scheduler-Verarbeitung 300 gemäß einigen Ausführungsbeispielen. Der Einfachheit halber wird 3 mit Bezug auf die oben beschriebenen Elemente von 1 beschrieben. In Block 302 empfängt der GPU-Scheduler 108 eine Auftragsanforderung 104 zur Planung eines neuen Auftrags, der von der/den GPU(s) des Computersystems 100 ausgeführt werden soll. Im Block 304 weist der GPU-Scheduler 108 den neuen Auftrag einer oder mehreren vGPUs zu. In Block 306 aktualisiert der GPU-Scheduler 108 die Zuweisungen bestehender Aufträge an eine oder mehrere vGPUs. In Block 308 minimiert der GPU-Scheduler die Betriebs- und Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisung bestehender Aufträge an eine oder mehrere vGPUs. In einer Ausführungsform werden die Zuweisung des neuen Auftrags an eine oder mehrere vGPUs, die Aktualisierung der Zuweisungen bestehender Aufträge an eine oder mehrere vGPUs und die Minimierung der Betriebs- und Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisung bestehender Aufträge an eine oder mehrere vGPUs in polynomialer Zeit durchgeführt, wie unten beschrieben wird. In einer Ausführungsform wird die Ausführung von Block 308 zumindest teilweise von Solver 122 übernommen. In Block 310 verarbeiten die zugewiesenen vGPUs (und damit auch die GPUs) des Computersystems 100 den neuen Auftrag und die bestehenden Aufträge.
  • In einer Ausführungsform werden die in 3 dargestellten Aktionen immer dann ausgeführt, wenn eine neue Auftragsanforderung eingeht. In einer anderen Ausführungsform werden die Aktionen der Blöcke 304 und 306 immer dann ausgeführt, wenn ein bestehender Auftrag abgeschlossen ist (außer wenn in diesem Fall kein neuer Auftrag zu bearbeiten ist, wird kein neuer Auftrag zugewiesen oder verarbeitet, sondern die Zuweisung der verbleibenden bestehenden Aufträge wird aktualisiert, und die verbleibenden bestehenden Aufträge werden verarbeitet). In einer anderen Ausführungsform werden die Aktionen der Blöcke 304, 306 und 308 atomar und gleichzeitig ausgeführt.
  • Der GPU Scheduler 108 bietet eine optimale Lösung für das GPU Scheduling Problem. Dieses Problem ist ein Beispiel für ein Bin-Packing-Problem, bei dem die Bins eingeschränkt sind (z. B. ist die Mindestgröße der Elemente in einem Bin eine Konstante). Ein Bin kann zum Beispiel eine vGPU darstellen und ein Item einen Job. Bei einem Bin-Packing-Problem mit Constraints ist die Gesamtkombination der Elemente in einem Bin gleich R = ( M + K M )
    Figure DE102021127324A1_0001
    wobei K die Anzahl der verschiedenen Größen von Behältern ist und M die Anzahl der Gegenstände ist. Daher ist die Gesamtkombination von Behältern mit R verschiedenen Behältern ist gleich P = ( n + R R ) ( n + R ) R = O ( n R ) ,
    Figure DE102021127324A1_0002
    die durch ein Polynom von n. Daher kann die Lösung des hier beschriebenen GPU-Planungsproblems in Polynomialzeit gelöst werden.
  • Der GPU-Scheduler 108 verwendet die folgenden Variablen als Eingangsdaten: 1) Der Satz von Aufträgen (bereits zugewiesene und neu zuzuweisende Aufträge); 2) Die bisherigen Zuweisungsentscheidungen kij ∀i,j der bestehenden Aufträge im System (wobei kij eine binäre Variable ist, die die vorherige Entscheidung über die Zuweisung eines Auftrags i zu GPU j3) Die Gewichte wi ∀i für die Migrationskosten jedes Auftrags; 4) die Gewichte, die der Systemadministrator für die Zielfunktionen wählt ∈1, ∈2 (wobei ∈1 für die Betriebskosten und ∈2 für die Migrationskosten steht); 5) die erforderliche Anzahl virtueller GPUs Ri ∀i; für jeden Auftrag; und 6) die Gesamtzahl N der physischen GPUs im System .
  • Der GPU-Scheduler 108 erzeugt die folgenden Variablen als Ausgabedaten: (1) Die neue Entscheidung xij ∀i,j über die Zuteilung aller Aufträge (bestehende und neue) im System, wobei xij die Entscheidung darstellt, den Job i zur GPU j(2) Die Anzahl der Job-Migrationen und die Migrationskosten; (3) Die binäre Entscheidung δi über die Migration eines Auftrags i (ja oder nein); und 4) die binäre Entscheidung yj ∀j GPU einschalten j einschalten oder nicht. GPU Scheduler 108 führt die Zuweisungsentscheidungen für die Jobs und die vGPUs zumindest teilweise auf der Grundlage der Ausgabedaten durch. Die GPUs verarbeiten dann die ihren vGPUs zugewiesenen Aufträge.
  • In Tabelle 1 sind die Eingangs- und Ausgangsvariablen aufgeführt. Tabelle 1
    Variabel Erläuterung
    1 Die Gewichtung (Priorität), die der Systemadministrator der ersten Zielfunktion geben kann, die die Betriebskosten minimiert (die Gesamtzahl der „eingeschalteten“ GPUs entspricht den Betriebskosten).
    2 Die Gewichtung (Priorität), die der Systemadministrator der zweiten Zielfunktion geben kann, die die Migrationskosten minimiert (die gewichtete Gesamtzahl der Jobmigrationen).
    y j Eine binäre Variable, die die Entscheidung darstellt, die GPU einzuschalten j einzuschalten, wenn yj 1 ist oder nicht, wenn yj 0 ist.
    δ i Eine binäre Variable, die die Entscheidung für die Migration eines Auftrags darstellt i wenn δi 1 ist oder nicht, wenn δi 0 ist.
    w i Die Gewichtung (Priorität), die der Systemadministrator den verschiedenen Aufträgen zuweisen kann, um die Migrationskosten festzulegen, wenn verschiedene Aufträge unterschiedliche Migrationskosten haben; z. B. könnte Auftrag 14 im Vergleich zu Auftrag 27 doppelt so viele Daten zu verschieben haben, und der Administrator kann wählen w14 = 2w27 um die Migrationskosten für jeden Auftrag anzugeben.
    R i Eine ganzzahlige Variable, die die Anzahl der für jeden Auftrag erforderlichen virtuellen GPUs angibt i.
    x ij Eine binäre Variable, die die Entscheidung über die Zuweisung eines Auftrags i an die GPU j zuzuweisen, wenn xij 1 ist und nicht zugewiesen wird, wenn xij 0 ist.
    B j Eine ganzzahlige Variable, die die Anzahl der virtuellen GPUs definiert, die in jeder physischen GPU vorhanden sind jdie vom Systemadministrator gewählt wird (je nachdem, wie die GPU j in virtuelle GPUs unterteilt ist).
    k ij Eine binäre Variable, die die vorherige Entscheidung über die Zuweisung eines Auftrags i an GPU j wenn kij 1 ist und nicht zugewiesen wird, wenn kij 0 ist.
    N Eine ganzzahlige Variable, die die Gesamtzahl der physischen GPUs im Rechensystem angibt.
  • Gleichung 1 und die Randbedingungen 1, 2, 3 und 4 stellen eine Formulierung des GPU-Zuweisungsproblems durch den GPU-Scheduler 108 dar, die zur Verarbeitung an den Solver 122 gesendet wird. M i n   ε 1 j y j + ε 2 i w i δ i
    Figure DE102021127324A1_0003
    • Einschränkung 1 s u b j e c t  to  i R i . x i j B j y j , j 1, N
      Figure DE102021127324A1_0004
    • Einschränkung 2 j x i j = 1
      Figure DE102021127324A1_0005
    • Einschränkung 3 δ i j ( x i j + k i j 2 x i j k i j ) | N |
      Figure DE102021127324A1_0006
    • Einschränkung 4 δ i , x i j , k i j { 0,1 }
      Figure DE102021127324A1_0007
  • Die Zielfunktion von Gleichung 1 besteht aus zwei Teilen: (i) die linke Seite zeigt die Betriebskosten für das Einschalten der (erforderlichen) GPUs im Rechensystem, verzerrt durch eine Konstante, die die Priorität der Betriebskosten in der Zielfunktion angibt; und (ii) die rechte Seite zeigt die gewichteten Migrationskosten der Aufträge. Bedingung 1 besagt, dass die Anzahl der einer physischen GPU zugewiesenen Jobs nicht größer sein darf als die Kapazität der physischen GPU. Bedingung 2 besagt, dass jeder Auftrag nur auf einer der physischen GPUs geplant werden kann.
  • Bedingung 3 verlangt, dass die Migration durchgeführt wird, wenn sich die neue Zuteilung von der aktuellen Zuteilung unterscheidet, indem die Variable δi im Falle einer Migration auf 1 und andernfalls auf 0 gesetzt wird. Dies wird in Tabelle 2 dargestellt. Tabelle 2
    x ij k ij δ i
    0 0 0
    1 1 0
    0 1 1
    1 0 1
  • Bedingung 4 verlangt, dass δi, xij, kij binäre Variablen sind, die entweder 0 oder 1 sein können.
  • Die hier beschriebene Technologie bietet einen GPU-Planungsprozess zur optimalen Zuweisung von Aufträgen an vGPUs unter Berücksichtigung der Betriebskosten und der Migrationskosten. Der Systemadministrator hat die Möglichkeit, das Kostenmodell auszuwählen und den Betriebskosten oder den Migrationskosten Vorrang einzuräumen, indem er ihre jeweilige Gewichtung anpasst wi. Der Systemadministrator kann die Anzahl der GPUs im Rechensystem N, die Anzahl der verfügbaren vGPUs, die Anzahl der vGPUs, in die jede physische GPU unterteilt ist, und die Anzahl der vGPUs, die jeder Auftrag im Laufe der Zeit benötigt, angeben Ri.
  • Die hier unter Bezugnahme auf die 1 bis 5 beschriebene Verarbeitung kann in Form von ausführbaren Befehlen, die auf einem maschinenlesbaren Medium gespeichert sind und von einer Verarbeitungsressource (z. B. einem Mikrocontroller, einem Mikroprozessor, einem oder mehreren Kernen einer Zentraleinheit, einer anwendungsspezifischen integrierten Schaltung (ASIC), einem feldprogrammierbaren Gate-Array (FPGA) und dergleichen) ausgeführt werden, und/oder in Form anderer Arten von elektronischen Schaltungen erfolgen. Diese Verarbeitung kann beispielsweise von einem oder mehreren Computersystemen oder -knoten in verschiedenen Formen durchgeführt werden, wie den oben unter Bezugnahme auf die 1 und 2 beschriebenen Systemen oder den unten unter Bezugnahme auf die 4 und 5 beschriebenen Knoten und/oder Computersystemen.
  • Die hier beschriebenen Ausführungsformen umfassen verschiedene Schritte, von denen oben Beispiele beschrieben wurden. Wie weiter oben beschrieben, können diese Schritte von Hardwarekomponenten ausgeführt werden oder in maschinenausführbaren Anweisungen verkörpert sein, die verwendet werden können, um einen mit den Anweisungen programmierten Prozessor zur Ausführung der Schritte zu veranlassen. Alternativ können zumindest einige Schritte durch eine Kombination von Hardware, Software und/oder Firmware ausgeführt werden.
  • Die hier beschriebenen Ausführungsformen können als Computerprogrammprodukt bereitgestellt werden, das ein greifbares, maschinenlesbares Speichermedium umfassen kann, auf dem Anweisungen verkörpert sind, die zur Programmierung eines Computers (oder anderer elektronischer Geräte) zur Durchführung eines Prozesses verwendet werden können. Das maschinenlesbare Medium kann unter anderem Festplattenlaufwerke, Magnetbänder, Disketten, optische Platten, Compact-Disc-Festwertspeicher (CD-ROMs) und magneto-optische Platten, Halbleiterspeicher, wie ROMs, PROMs, Direktzugriffsspeicher (RAMs), programmierbare Festwertspeicher (PROMs), löschbare PROMs (EPROMs), elektrisch löschbare PROMs (EEPROMs), Flash-Speicher, magnetische oder optische Karten oder andere Arten von Medien/Maschinen-lesbaren Medien, die zur Speicherung elektronischer Befehle geeignet sind (z.g., Computerprogrammiercode, wie Software oder Firmware).
  • Verschiedene hierin beschriebene Verfahren können durch die Kombination eines oder mehrerer maschinenlesbarer Speichermedien, die den Code gemäß den hierin beschriebenen Beispielausführungen enthalten, mit geeigneter Standard-Computerhardware zur Ausführung des darin enthaltenen Codes durchgeführt werden. Eine Vorrichtung zum Ausführen verschiedener hierin beschriebener Ausführungsformen kann ein oder mehrere Rechenelemente oder Computer (oder einen oder mehrere Prozessoren innerhalb eines einzelnen Computers) und Speichersysteme umfassen, die Computerprogramme enthalten oder über ein Netzwerk auf diese zugreifen können, die in Übereinstimmung mit verschiedenen hierin beschriebenen Methoden kodiert sind, und die Verfahrensschritte verschiedener hierin beschriebener Ausführungsformen können durch Module, Routinen, Unterprogramme oder Unterteile eines Computerprogrammprodukts ausgeführt werden.
  • 4 ist ein Blockdiagramm eines Verarbeitungsknotens 400 eines Systems (z. B. des Computersystems 100) gemäß einer Beispielsausführungsform. In dem in 4 dargestellten Beispiel umfasst der Knoten 400 eine Verarbeitungsressource 410, die mit einem nicht transitorischen, maschinenlesbaren Medium 420 gekoppelt ist, das mit Befehlen zur Durchführung der Zeitplanung kodiert ist. Die Verarbeitungsressource 410 kann einen Mikrocontroller, einen Mikroprozessor, einen oder mehrere CPU-Kerne, eine Grafikverarbeitungseinheit (GPU), einen ASIC, einen FPGA und/oder eine andere Hardwarevorrichtung umfassen, die zum Abrufen und/oder Ausführen von Befehlen vom maschinenlesbaren Medium 420 geeignet ist, um die Funktionen in Bezug auf verschiedene hier beschriebene Beispiele durchzuführen. Zusätzlich oder alternativ kann die Verarbeitungsressource 410 eine elektronische Schaltung zur Ausführung der Funktionalität der hier beschriebenen Anweisungen enthalten.
  • Das maschinenlesbare Medium 420 kann ein beliebiges Medium sein, das zum Speichern von ausführbaren Anweisungen geeignet ist. Nicht einschränkende Beispiele für ein maschinenlesbares Medium 420 sind ein Speicher mit wahlfreiem Zugriff (RAM), ein Festwertspeicher (ROM), ein elektrisch löschbarer Festwertspeicher (EEPROM), ein Flash-Speicher, ein Festplattenlaufwerk, eine optische Platte oder Ähnliches. Das maschinenlesbare Medium 420 kann, wie in 4 dargestellt, innerhalb des Knotens 400 angeordnet sein, wobei die ausführbaren Anweisungen als auf dem Knoten 400 „installiert“ oder „eingebettet“ angesehen werden können. Alternativ kann das maschinenlesbare Medium 420 ein tragbares (z. B. externes) Speichermedium sein und Teil eines „Installationspakets“ sein. „Die auf dem maschinenlesbaren Medium 420 gespeicherten Anweisungen können nützlich sein, um zumindest einen Teil der hier beschriebenen Verfahren zu implementieren.
  • Wie weiter unten beschrieben, kann auf dem maschinenlesbaren Medium 420 ein Satz von ausführbaren Anweisungen 430, 440, 450 und 460 gespeichert sein. Es versteht sich, dass ein Teil oder die Gesamtheit der ausführbaren Befehle und/oder elektronischen Schaltungen, die in einem Gehäuse enthalten sind, in alternativen Implementierungen in einem anderen, in den Figuren dargestellten Gehäuse oder in einem anderen, nicht dargestellten Gehäuse enthalten sein können. In einigen Implementierungen kann das maschinenlesbare Medium 420 weitere, nicht dargestellte Befehle enthalten, um andere hier beschriebene Funktionen auszuführen, wie z. B. die Festlegung einer Schreibgewichtung oder eines Wahl-Timeouts.
  • Die Anweisungen 430 veranlassen bei ihrer Ausführung die Verarbeitungsressource 410, die Scheduler 116-Verarbeitung durchzuführen. In einer Ausführungsform umfasst die Scheduler-Verarbeitung die Ausführung eines Prozesses durch eine Verarbeitungsressource auf dem Computersystem 100, um Auftragsanforderungen an Rechenressourcen innerhalb des Computersystems 100 (z. B. CPUs, ASICs, FPGAs usw.) zuzuweisen. Die Scheduler-Anweisungen 430 rufen GPU-Scheduler-Anweisungen 440 auf. Die Anweisungen 440 veranlassen bei ihrer Ausführung die Verarbeitungsressource 410, die GPU-Scheduler-Verarbeitung durchzuführen. In einer Ausführungsform umfasst die GPU-Scheduler-Verarbeitung die Ausführung eines Prozesses durch eine Verarbeitungsressource im Computersystem 100, um den GPUs im Computersystem 100 Aufträge optimal zuzuweisen. Die Anweisungen 450 veranlassen die Verarbeitungsressource 410 bei der Ausführung, die Verarbeitung der Anwendung 100 durchzuführen. In einer Ausführungsform umfasst die Verarbeitung der Anwendung 102 jede gewünschte Datenverarbeitung, die von einem Benutzer der Anwendung angewiesen wird. Die Ausführung der Anwendungsanweisungen 450 führt zu Aufrufen der Scheduler-Anweisungen 430. Die GPU-Scheduler-Anweisungen 440 rufen die Solver-Anweisungen 460 auf. Die Anweisungen 460 veranlassen bei ihrer Ausführung die Verarbeitungsressource 410, eine Solver-Verarbeitung durchzuführen (z. B. eine Lösung für das lineare Programmproblem der GPU-Zuweisung zu generieren).
  • 5 ist ein Blockdiagramm, das einen Knoten 500 zeigt, der die Knoten eines Systems (wie das Computersystem 100) gemäß einer Ausführungsform darstellen kann. Im Kontext des vorliegenden Beispiels weist der Knoten 500 eine softwarezentrierte Architektur auf, die Rechen-, Speicher-, Netzwerk- und Virtualisierungsressourcen sowie andere Technologien integriert.
  • Knoten 500 kann als physischer Server (z. B. ein Server mit einer x86- oder ARM-Architektur) oder ein anderes geeignetes Rechengerät implementiert werden. Im vorliegenden Beispiel beherbergt der Knoten 500 eine Anzahl n virtueller Gastmaschinen (VM) 502, 504 und 506 (wobei n eine natürliche Zahl ist) und kann so konfiguriert werden, dass er die hier beschriebene GPU-Planung durchführt. In einigen Ausführungsformen können mehrere solcher Knoten, die jeweils den Scheduler 106, den GPU-Scheduler 108 und die Verarbeitung der Anwendung 102 (wie oben in Verbindung mit den 1 bis 4 beschrieben) ausführen, mit einem Netzwerk verbunden und als Teil eines Clusters konfiguriert sein. Abhängig von der jeweiligen Implementierung können ein oder mehrere vom System unterstützte Dienste mit den VMs 502, 504 und 506 in Verbindung stehen oder unabhängig davon sein.
  • Der Knoten 500 kann eine virtuelle Anwendung 508 über einem Hypervisor 510 enthalten. Das virtuelle Gerät 508 kann den Scheduler 106, den GPU-Scheduler 108, den Solver 122 und die Anwendung 102 umfassen. Die virtuelle Anwendung 508 kann ein virtuelles Dateisystem 512 enthalten, das mit einer Steuerungsebene 514 und einem Datenpfad 516 kommuniziert. Die Steuerebene 514 kann den Datenfluss zwischen Anwendungen und Ressourcen innerhalb des Knotens 500 steuern. Der Datenpfad 516 kann eine geeignete Eingabe-/Ausgabeschnittstelle (E/A) zwischen dem virtuellen Dateisystem 512 und einem Betriebssystem (OS) 518 bereitstellen. In einer Ausführungsform sind der Scheduler 106 und der GPU-Scheduler 108 in das Betriebssystem 518 integriert. Gemäß einer Ausführungsform stellt die virtuelle Appliance 508 einen virtuellen Controller dar, der so konfiguriert ist, dass er Storage-Stack-Software (nicht dargestellt) ausführt, die dazu verwendet werden kann, Funktionen auszuführen, wie z. B. die Verwaltung des Zugriffs von VMs 502, 504 und 506 auf Speicher 520, die Bereitstellung einer dynamischen Ressourcennutzung, das Verschieben von VM-Daten zwischen Speicherressourcen 522 und 524, die Bereitstellung von Datenbewegungen und/oder die Ausführung anderer Funktionen eines hyperkonvergenten Rechenzentrums.
  • Der Knoten 500 kann auch eine Reihe von Hardwarekomponenten unterhalb des Hypervisors 510 enthalten. Beispielsweise kann der Knoten 500 einen Speicher 520 umfassen, bei dem es sich um einen RAID-Speicher (Redundant Array of Independent Disks) mit einer Reihe von Festplattenlaufwerken (HDDs) 522 und/oder Solid-State-Laufwerken (SSDs) 524 handeln kann. Knoten 500 kann auch Speicher 526 (z. B. Direktzugriffsspeicher (RAM), Festwertspeicher (ROM), Flash usw.) und einen oder mehrere Prozessoren 528 enthalten. Der Knoten 500 kann drahtlose und/oder drahtgebundene Netzwerkschnittstellenkomponenten enthalten, um die Kommunikation über ein Netzwerk 530 (z. B. mit anderen Knoten oder mit dem Internet) zu ermöglichen. Der Knoten 500 kann auch eine oder mehrere GPUs 536 enthalten.
  • In der vorstehenden Beschreibung sind zahlreiche Details aufgeführt, um das Verständnis des hierin offengelegten Gegenstands zu erleichtern. Die Umsetzung kann jedoch auch ohne einige oder alle diese Details erfolgen. Andere Ausführungsformen können Modifikationen und Abweichungen von den oben beschriebenen Details enthalten. Es ist beabsichtigt, dass die folgenden Ansprüche solche Modifikationen und Variationen abdecken.

Claims (20)

  1. Ein Verfahren, das Folgendes umfasst: Empfangen, in einem Computersystem, das eine oder mehrere Grafikverarbeitungseinheiten (GPUs) enthält, wobei die eine oder mehreren GPUs die gleichzeitige Verarbeitung einer Vielzahl von Aufträgen durch eine Vielzahl von virtuellen GPUs (vGPUs ) bereitstellen, einer Anforderung, einen neuen Auftrag zu planen, der von dem Computersystem ausgeführt werden soll; Zuweisung des neuen Auftrags an eine oder mehrere vGPUs; Aktualisierung der Zuweisungen bestehender Aufträge an eine oder mehrere vGPUs; Minimierung der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisungen der bestehenden Aufträge an die eine oder mehreren vGPUs; und Verarbeitung des neuen Auftrags und der bestehenden Aufträge mit aktualisierten Zuweisungen durch die eine oder mehrere GPUs im Rechensystem.
  2. Das Verfahren nach Anspruch 1, wobei die eine oder die mehreren GPUs des Rechensystems heterogen sind.
  3. Das Verfahren nach Anspruch 1, wobei das Aktualisieren von Zuweisungen bestehender Aufträge das Migrieren eines bestehenden Auftrags auf eine andere GPU umfasst.
  4. Das Verfahren nach Anspruch 1, wobei das Aktualisieren und Minimieren durchgeführt wird, wenn ein bestehender Auftrag abgeschlossen ist.
  5. Das Verfahren nach Anspruch 1, umfassend das Erhalten von Gewichtungen für die Betriebskosten und die Migrationskosten.
  6. Das Verfahren nach Anspruch 1, wobei das Minimieren der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und das Aktualisieren der Zuweisungen der vorhandenen Aufträge an die eine oder mehreren vGPUs das Empfangen eines Satzes vorhandener Aufträge, von Zuweisungsentscheidungen der vorhandenen Aufträge, von Gewichtungen für Migrationskosten neuer und vorhandener Aufträge, von Gewichtungen für Betriebskosten und Migrationskosten zweier Zielfunktionen, einer Anzahl von vGPUs, die für jeden Auftrag erforderlich sind, und einer Anzahl von GPUs in dem Rechensystem durch einen GPU-Scheduler umfasst.
  7. Das Verfahren nach Anspruch 1, wobei die Minimierung der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisungen der vorhandenen Aufträge an die eine oder die mehreren vGPUs das Bestimmen von Entscheidungen für die Zuweisung neuer und vorhandener Aufträge, einer Anzahl von Auftragsmigrationen und Migrationskosten, von Entscheidungen über die Migration vorhandener Aufträge und von Entscheidungen über das Ausschalten/Einschalten der GPUs durch einen GPU-Scheduler umfasst.
  8. Das Verfahren nach Anspruch 1, bei dem die Minimierung der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisungen der bestehenden Aufträge an die eine oder die mehreren vGPUs das Bestimmen minimierter Betriebskosten für das Einschalten einer Vielzahl von GPUs und minimierter Migrationskosten für die Migration bestehender Aufträge durch einen GPU-Scheduler umfasst, so dass eine Anzahl von Aufträgen, die einer GPU zugewiesen sind, nicht größer sein kann als eine Kapazität der GPU, der neue Auftrag auf nur einer GPU geplant werden kann und die Migration eines Auftrags durchgeführt wird, wenn eine neue Zuweisung eines bestehenden Auftrags sich von einer aktuellen Zuweisung eines bestehenden Auftrags unterscheidet.
  9. Ein nicht-transitorisches, maschinenlesbares Speichermedium, auf dem ausführbare Anweisungen gespeichert sind, die, wenn sie von einer Verarbeitungsressource ausgeführt werden, die Verarbeitungsressource veranlassen,: in einem Computersystem, das eine oder mehrere Grafikverarbeitungseinheiten (GPUs) enthält, wobei die eine oder die mehreren GPUs die gleichzeitige Verarbeitung einer Vielzahl von Aufträgen durch eine Vielzahl von virtuellen GPUs (vGPUs) bereitstellen, eine Anforderung zur Planung eines neuen Auftrags, der von dem Computersystem ausgeführt werden soll, empfangen; den neuen Auftrag einer oder mehreren vGPUs zuweisen; Zuweisungen bestehender Aufträge an eine oder mehrere vGPUs aktualisieren; Minimierung der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisungen der bestehenden Aufträge an die eine oder mehreren vGPUs; und Verarbeitung des neuen Auftrags und der bestehenden Aufträge durch einen oder mehrere Grafikprozessoren im Rechensystem.
  10. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 9, wobei die eine oder die mehreren GPUs des Computersystems heterogen sind.
  11. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 9, wobei die Anweisungen, die Verarbeitungsressource zu veranlassen, Zuweisungen bestehender Aufträge zu aktualisieren, Anweisungen umfassen, die Verarbeitungsressource zu veranlassen, einen bestehenden Auftrag zu einer anderen GPU zu migrieren.
  12. Das nicht-übertragbare maschinenlesbare Medium nach Anspruch 9, , wobei die Aktualisierungs- und Minimierungsanweisungen ausgeführt werden, wenn ein bestehender Auftrag abgeschlossen ist.
  13. Das nicht-transitorische maschinenlesbare Medium nach Anspruch 9, das Anweisungen umfasst, die bei ihrer Ausführung die Verarbeitungsressource veranlassen, Gewichtungen für die Betriebskosten und die Migrationskosten zu erhalten.
  14. Ein Rechnersystem, das Folgendes umfasst: eine oder mehrere Grafikverarbeitungseinheiten (GPUs), wobei die eine oder mehreren GPUs die gleichzeitige Verarbeitung einer Vielzahl von Aufträgen durch eine Vielzahl von virtuellen GPUs (vGPUs) ermöglichen; und einen GPU-Scheduler, um eine Anforderung zu empfangen, einen neuen Auftrag zu planen, der von dem Rechensystem ausgeführt werden soll, den neuen Auftrag einer oder mehreren vGPUs zuzuweisen, Zuweisungen bestehender Aufträge an eine oder mehrere vGPUs zu aktualisieren und Betriebskosten für den Betrieb der einen oder mehreren GPUs und Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisungen der bestehenden Aufträge an die eine oder mehreren vGPUs zu minimieren; wobei die eine oder mehrere GPUs den neuen Auftrag und die bestehenden Aufträge verarbeiten.
  15. Das Rechensystem nach Anspruch 14, wobei die eine oder die mehreren GPUs des Rechensystems heterogen sind.
  16. Das Rechensystem nach Anspruch 14, wobei der GPU-Scheduler zum Aktualisieren von Zuweisungen bestehender Jobs den GPU-Scheduler zum Migrieren eines bestehenden Jobs zu einem anderen GPU umfasst.
  17. Das Rechensystem nach Anspruch 14, wobei die Aktualisierung und Minimierung durchgeführt werden, wenn ein bestehender Auftrag abgeschlossen ist.
  18. Das Rechensystem nach Anspruch 14, wobei der GPU-Scheduler Gewichtungen für die Betriebskosten und die Migrationskosten erhält.
  19. Das Rechensystem nach Anspruch 14, wobei das Minimieren der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und das Aktualisieren der Zuweisungen der vorhandenen Aufträge an die eine oder mehreren vGPUs das Empfangen eines Satzes vorhandener Aufträge, von Zuweisungsentscheidungen der vorhandenen Aufträge, von Gewichtungen für Migrationskosten neuer und vorhandener Aufträge, von Gewichtungen für Betriebskosten und Migrationskosten zweier Zielfunktionen, einer Anzahl von vGPUs, die für jeden Auftrag erforderlich sind, und einer Anzahl von GPUs in dem Computersystem durch den GPU-Scheduler umfasst.
  20. Das Rechensystem nach Anspruch 14, wobei die Minimierung der Betriebskosten für den Betrieb der einen oder mehreren GPUs und der Migrationskosten für die Zuweisung des neuen Auftrags und die Aktualisierung der Zuweisungen der vorhandenen Aufträge an die eine oder die mehreren vGPUs das Bestimmen von Entscheidungen für die Zuweisung neuer und vorhandener Aufträge, einer Anzahl von Auftragsmigrationen und Migrationskosten, von Entscheidungen über die Migration vorhandener Aufträge und von Entscheidungen über das Ausschalten/Einschalten der GPUs durch den GPU-Scheduler umfasst.
DE102021127324.2A 2021-06-28 2021-10-21 Planung von aufträgen auf grafischen verarbeitungseinheiten Pending DE102021127324A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/360,122 US11651470B2 (en) 2021-06-28 2021-06-28 Scheduling jobs on graphical processing units
US17/360,122 2021-06-28

Publications (1)

Publication Number Publication Date
DE102021127324A1 true DE102021127324A1 (de) 2022-12-29

Family

ID=84388263

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021127324.2A Pending DE102021127324A1 (de) 2021-06-28 2021-10-21 Planung von aufträgen auf grafischen verarbeitungseinheiten

Country Status (3)

Country Link
US (2) US11651470B2 (de)
CN (1) CN115599512A (de)
DE (1) DE102021127324A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12007942B2 (en) 2021-10-27 2024-06-11 EMC IP Holding Company LLC Methods and systems for seamlessly provisioning client application nodes in a distributed system
US20230126511A1 (en) * 2021-10-27 2023-04-27 EMC IP Holding Company LLC Methods and systems for storing data in a distributed system using gpus
US11922071B2 (en) 2021-10-27 2024-03-05 EMC IP Holding Company LLC Methods and systems for storing data in a distributed system using offload components and a GPU module
CN116757915B (zh) * 2023-08-16 2023-11-28 北京蓝耘科技股份有限公司 一种集群gpu资源调度方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9135741B2 (en) * 2012-01-23 2015-09-15 Nec Laboratories America, Inc. Interference-driven resource management for GPU-based heterogeneous clusters
TWI479422B (zh) * 2013-01-25 2015-04-01 Wistron Corp 電腦系統及其繪圖處理方法
US9904975B2 (en) * 2015-11-11 2018-02-27 Amazon Technologies, Inc. Scaling for virtualized graphics processing
CA3004888C (en) * 2015-11-11 2020-09-08 Amazon Technologies, Inc. Scaling for virtualized graphics processing
US10282811B2 (en) * 2017-04-07 2019-05-07 Intel Corporation Apparatus and method for managing data bias in a graphics processing architecture
US11720408B2 (en) * 2018-05-08 2023-08-08 Vmware, Inc. Method and system for assigning a virtual machine in virtual GPU enabled systems
CN109376009A (zh) 2018-09-26 2019-02-22 郑州云海信息技术有限公司 一种共享资源的方法及装置
US20210110089A1 (en) 2019-10-10 2021-04-15 Nvidia Corporation Generating computer simulations of manipulations of materials based on machine learning from measured statistics of observed manipulations
US11113782B2 (en) * 2019-10-15 2021-09-07 Vmware, Inc. Dynamic kernel slicing for VGPU sharing in serverless computing systems
CN111506404A (zh) 2020-04-07 2020-08-07 上海德拓信息技术股份有限公司 一种基于Kubernetes的共享GPU调度方法
US20220050714A1 (en) * 2020-08-14 2022-02-17 Lancium Llc Power aware scheduling
CN111966500B (zh) 2020-09-07 2023-08-11 网易(杭州)网络有限公司 资源调度方法、装置、电子设备及存储介质
US20210117246A1 (en) * 2020-09-25 2021-04-22 Intel Corporation Disaggregated computing for distributed confidential computing environment
CN112286645B (zh) * 2020-12-29 2021-03-23 北京泽塔云科技股份有限公司 一种gpu资源池调度系统及方法

Also Published As

Publication number Publication date
CN115599512A (zh) 2023-01-13
US20240095870A1 (en) 2024-03-21
US20220414817A1 (en) 2022-12-29
US11651470B2 (en) 2023-05-16

Similar Documents

Publication Publication Date Title
DE102021127324A1 (de) Planung von aufträgen auf grafischen verarbeitungseinheiten
DE69910826T2 (de) Rechnersystem mit rekonfigurierbarer programmierbarer logik-vorrichtung
DE112011102183B4 (de) Beschleuniger für die Migration virtueller Maschinen
DE60307532T2 (de) Paralleles Prozess-Ausführungsverfahren und Mehrprozessorenrechner
DE102021109774A1 (de) Container-as-a-service (CAAS)-Controller für die Auswahl einer Bare-Metal-Maschine einer privaten Cloud für einen Cluster eines verwalteten Containerdienstes
DE112011100094T5 (de) Verfahren und System zum Abstrahieren eines auf nichtfunktionalen Anforderungen beruhenden Einsatzes von virtuellen Maschinen
DE112021006130T5 (de) Automatisierte orchestrierung von containern durch bewerten von mikrodiensten
DE102021109511A1 (de) Container-as-a- service (caas)-controller für die überwachung von clustern und die implementierung von autoscaling-richtlinien
DE102010044529B4 (de) Autonomes speicher-sub-system mit hardwarebeschleuniger
DE112010003554T5 (de) Symmetrische Direktmigration von Virtuellen Maschinen
DE102010001339A1 (de) Verwalten von Anforderungen von Betriebssystemen, die in virtuellen Maschinen ablaufen
DE112015004564B4 (de) Ereignisgesteuerte Reoptimierung einer logisch partitionierten Umgebung zur Energieverwaltung
DE102005029852A1 (de) Multiprozessorsystem mit mehreren Speicherpositionen zum jeweiligen Speichern von TLB-Abschussdaten für mehrere Prozessorknoten
DE112020002189T5 (de) Container-basierte anwendungen
DE102015002191A1 (de) Sicherheits-Hypervisor-Funktion
DE112020004661T5 (de) Ermitteln einer optimalen Anzahl von Threads pro Kern in einem Mehrkern-Prozessorkomplex
DE112013006646B4 (de) Computer, System und computerlesbares Ablagemedium zum Identifizieren von Arbeitslast und Dimensionierung von Puffern zum Zweck der Volumenreplikation
DE112020005323T5 (de) Elastische ausführung von machine-learning-arbeitslasten unter verwendung einer anwendungsbasierten profilierung
DE112021000390T5 (de) Anpassen der leistung eines datenverarbeitungssystems
DE112020005789T5 (de) Hierarchische partitionierung von operatoren
DE112020001774T5 (de) Datensatzabhängiges niedrigrang-zerlegen von neuronalen netzwerken
DE112020000865T5 (de) Speicherverwaltungssystem
DE112021005586T5 (de) Automatisches skalieren einer abfrage-steuerungsroutine für arbeitslasten im bereich big data auf unternehmensebene
DE112020003825T5 (de) Entsprechung zwischen externen Operationen und Containern sowie Mutationsereignissen
DE102020103521A1 (de) Minimieren der Nutzung von Hardware-Zählern bei getriggerten Operationen für kollektive Kommunikation

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TX, US

R012 Request for examination validly filed