-
Die vorliegende Erfindung betrifft ein Verfahren zum Betreiben einer Recheneinheit sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung.
-
Hintergrund der Erfindung
-
Anwendungen bzw. Prozesse in Fahrzeugen, die z.B. das autonome bzw. automatisierte Fahren betreffen, können sehr rechen- und datenintensiv sein. Entsprechend gibt es einen Trend zur Verwendung von Hochleistungs-Computerplattformen in cyber-physischen Systemen (z.B. durch Auslagerung in fahrzeugfremde Rechensysteme (sog. „Cloud“)). Derartige Plattformen können zur Ausführung verschiedener Prozesse mit verschiedenen Qualitätsanforderungen bezüglich Güte bzw. Dienstgüte (engl. „Quality of Service“, QoS) verwendet werden, beispielsweise mit individuellen Anforderungen bezüglich Latenzzeit, Durchsatz oder sog. „Best Effort“. „Quality of Service“ ist ein Maß dafür, wie stark die Güte eines Dienstes mit den Anforderungen übereinstimmt.
-
Typischerweise gibt es auf solchen Plattformen unterschiedliche Einheiten wie CPU-Cluster, GPUs oder andere benutzerdefinierte Hardwarebeschleuniger (auch als Speichermaster oder Master bezeichnet), die alle über eine Verbindung auf eine gemeinsam genutzte Ressource zugreifen können, z.B. auf einen gemeinsam genutzten Speicher (Slave). Hierbei konkurriert eine Anwendung, die auf einem bestimmten Kern (darunter ist insbesondere einer von mehreren Prozessorkernen der CPU bzw. des CPU-Clusters zu verstehen) ausgeführt wird, zunächst mit Anwendungen auf anderen Kernen um den Speicher. Außerdem können andere Master wie die GPU um den gemeinsam genutzten Speicher über die gemeinsam genutzte Verbindung mit der CPU konkurrieren.
-
Es hat sich gezeigt, dass ein Prozess aufgrund des Zugriffs auf gemeinsam genutzte Ressourcen wie etwa den Hauptspeicher eine erhebliche Verlängerung der Ausführungszeit erleiden kann, wenn dieser Prozess zusammen mit anderen Prozessen auf einer gemeinsamen Multi-Core-Plattform ausgeführt wird. Diese Konkurrenz mit anderen Mastern verschärft das Problem nochmals. Es ist daher von Bedeutung, eine Störungsfreiheit und zeitliche Entkopplung bei der gemeinsamen Ausführung verschiedener Prozesse auf Multicore-Plattformen zu ermöglichen, insbesondere für Prozesse mit Echtzeitanforderungen.
-
Offenbarung der Erfindung
-
Erfindungsgemäß werden ein Verfahren zum Betreiben einer Recheneinheit sowie eine Recheneinheit und ein Computerprogramm zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
-
In der Recheneinheit wird eine Vielzahl von Prozessen bzw. Anwendungen ausgeführt, welche gemeinsam gemäß einer vorgegebenen Ressourcenverteilung auf eine Ressource zugreifen. Die Erfindung bedient sich der Maßnahme, einzelnen Prozessen jeweils eine einzuhaltende Laufzeit bzw. Abarbeitungszeit sowie jeweils eine zulässige Laufzeitverlängerung als Toleranz zuzuweisen. Können diese Vorgaben nicht eingehalten werden, beispielsweise, weil es zu Konflikten bei den Zugriffen auf die gemeinsame Ressource kommt, wird die Verteilung der Ressource auf die einzelnen Prozesse angepasst.
-
Insbesondere weist die Recheneinheit eine Prozessoreinheit mit einer Vielzahl von Prozessorkernen auf, welche die Vielzahl von Prozessen ausführt und welche gemeinsam an die entsprechende Ressource angebunden sind, z.B. über eine Datenverbindung wie etwa einen Bus. Eine derartige Prozessoreinheit kann beispielsweise als eine CPU („Central Processing Unit“), eine GPU („Graphics Processing Unit“) oder beispielsweise auch als ein DMA bzw. DMA-Controller („Direct Memory Access“) oder als ein dedizierter Beschleuniger ausgebildet sein.
-
Besonders zweckmäßig kann diese gemeinsam genutzte Ressource eine Speichereinheit sein, z.B. ein gemeinsamer Arbeitsspeicher, d.h. insbesondere ein flüchtiger Speicher wie z.B. DRAM (dynamischer Random Access Memory). Eine derartige Speichereinheit verfügt über eine Bandbreite oder Speicherbandbreite, also eine Rate an Daten, die pro Zeiteinheit gelesen und/oder geschrieben werden können. Diese Bandbreite ist nicht notwendigerweise konstant. Ein DRAM z.B. weist eigene interne Optimierungsmechanismen (vgl. mit z.B. Caches) auf, so dass je nach Zugriffsreihenfolge auf Speicheradressen und einer Lokalität der Daten diese Bandbreite höher oder niedriger sein kann. Unabhängig davon müssen sich die Prozessorkerne und somit die ausgeführten Prozesse die verfügbare Bandbreite teilen.
-
Ferner kann die gemeinsam genutzte Ressource beispielsweise auch eine Rechenkapazität der Recheneinheit bzw. der Prozessoreinheit sein, beispielsweise, wenn einzelne Prozesse nicht fest einem bestimmten Prozessorkern zugewiesen sind, sondern von mehreren Kernen ausgeführt werden können. Beispielsweise kann die gemeinsam genutzte Ressource auch ein Modul in der Recheneinheit oder eine andere Einheit sein, z.B. ein Peripheriegerät.
-
Gemäß der vorgegebenen Ressourcenverteilung werden zweckmäßigerweise die Zugriffe der einzelnen Prozessorkerne und somit der einzelnen Prozesse auf die gemeinsam genutzte Ressource reguliert. Besonders zweckmäßig wird durch diese Ressourcenverteilung bei einer gemeinsam genutzten Speichereinheit die zur Verfügung stehende Speicherbandbreite auf die einzelnen Prozessorkerne und Prozesse aufgeteilt. Durch das vorliegende Verfahren wird eine Möglichkeit bereitgestellt, um die Ressourcenverteilung auf die gemeinsam genutzte Ressource während des Betriebes der Recheneinheit dynamisch anzupassen, um die Anforderungen der einzelnen Prozesse erfüllen zu können.
-
Zu diesem Zweck werden im Rahmen des vorliegenden Verfahrens einzelnen oder insbesondere allen Prozessen jeweils eine Soll-Abarbeitungszeit bzw. eine Soll-Ausführungszeit und eine zulässige Abarbeitungszeitverlängerung zugewiesen bzw. vorgegeben. Dabei soll der jeweilige Prozess innerhalb der jeweiligen zugewiesenen Soll-Abarbeitungszeit insbesondere vollständig abgearbeitet bzw. ausgeführt werden. Eine Ist-Abarbeitungszeit des jeweiligen Prozesses darf von der jeweiligen zugewiesenen Soll-Abarbeitungszeit maximal um die jeweilige zugewiesene Abarbeitungszeitverlängerung abweichen. Eine Abweichung der Ist-Abarbeitungszeit von der Soll-Abarbeitungszeit tritt insbesondere dann auf, wenn mehrere Prozesse parallel auf die gemeinsame Ressource zugreifen. Wenn die Ist-Abarbeitungszeit die Soll-Abarbeitungszeit dabei um mehr als die jeweilige (zulässige) Abarbeitungszeitverlängerung überschreitet, kann eine Funktionalität des jeweiligen Prozesses oder gar der gesamten Recheneinheit beeinträchtigt werden.
-
Zweckmäßigerweise stellt die Soll-Abarbeitungszeit einen Richtwert oder Bezugswert für die Laufzeit des jeweiligen Prozesses dar und kann beispielsweise einer Laufzeit entsprechen, die zu erwarten ist, wenn der jeweilige Prozess isoliert bzw. unabhängig von weiteren, um die Ressource konkurrierenden Prozessen ausgeführt wird und somit exklusiv auf die entsprechend Ressource zugreifen kann. Eine Summe aus der Soll-Abarbeitungszeit und der Abarbeitungszeitverlängerung kann besonders zweckmäßig als ein zulässiger Schwellwert bzw. ein zulässiger Grenzwert für die Ist-Abarbeitungszeit vorgegeben werden. Insbesondere kann die Abarbeitungszeitverlängerung einem zulässigen Prozentsatz oder einer absoluten Zeit entsprechen, um welchen sich die Soll-Abarbeitungszeit maximal verlängern darf, wenn aufgrund des gemeinsamen Zugriffs auf die Ressource entsprechende Verzögerungseffekte auftreten.
-
Die Soll-Ausführungszeit bzw. Abarbeitungszeit kann global für den ganzen Prozess oder auf Intervallebene betrachtet und angegeben werden. Die Soll-Abarbeitungszeiten sowie die Abarbeitungszeitverlängerungen können jeweils beispielsweise als absolute Zeitwerte angegeben werden oder zweckmäßigerweise auch als relative Werte, aus welchen absolute Zeitwerte abgeleitet werden können. Beispielsweise können die Soll-Abarbeitungszeiten und die Abarbeitungszeitverlängerungen jeweils als Zählerwerte eines Leistungszählers, Hardware-Leistungszähler oder Hardware-Zählers (engl. „performance monitoring counter“, PMC, oder „performance monitoring unit“, PMU) vorgegeben werden, welcher bestimmte Vorgänge oder Aktivitäten in der Recheneinheit misst bzw. zählt. Die Arbeitszeitveränderung können ferner beispielsweise als prozentuale Abweichungen von diesen Zählerwerten vorgegeben werden. Basierend auf derartigen Zählerwerten ergeben sich die entsprechenden Laufzeiten bzw. die entsprechenden Soll-Abarbeitungszeiten und Abarbeitungszeitverlängerungen durch die Zielhardwareplattform zweckmäßigerweise von selbst.
-
Während der Ausführung der einzelnen Prozesse in der Recheneinheit werden aktuelle Ist-Abarbeitungszeiten der einzelnen Prozesse bestimmt bzw. ermittelt, in denen die einzelnen Prozesse aktuell tatsächlich abgearbeitet werden. Diese Ist-Abarbeitungszeiten der einzelnen Prozesse werden mit den jeweiligen zugewiesenen Soll-Abarbeitungszeiten verglichen und/oder mit einer Summe der jeweiligen zugewiesenen Soll-Abarbeitungszeiten und der jeweiligen zugewiesenen Abarbeitungszeitverlängerung. In Abhängigkeit von einem Ergebnis dieses Vergleichs wird die Ressourcenverteilung angepasst. Somit wird insbesondere überwacht, ob und, wenn ja, wie stark die tatsächlichen Ist-Abarbeitungszeiten der einzelnen Prozesse im regulären Betrieb der Recheneinheit von den vorgegebenen Soll-Werten abweichen. Weichen einzelne Ist-Zeiten von den jeweiligen Soll-Abarbeitungszeiten ab, deutet dies insbesondere darauf hin, dass es zu Konflikten einzelner Prozesse bei dem Zugriff auf die gemeinsame Ressource kommt, wodurch die Abarbeitungszeiten von Prozessen verzögert werden. Weichen einzelne Ist-Abarbeitungszeiten von den zugewiesenen Soll-Abarbeitungszeiten gar um mehr als die jeweilige zulässige Abarbeitungszeitverlängerung ab, bewegt sich das System außerhalb des Zulässigen und es können beispielsweise entsprechende Prozesse aufgrund von Zugriffskonflikten bezüglich der gemeinsamen Ressource negativ beeinträchtigt werden und es kann zu Instabilitäten des Systems kommen.
-
Abhängig davon, ob und wie stark zugehörige Ist- und Soll-Abarbeitungszeiten voneinander abweichen, wird die Ressourcenverteilung zweckmäßigerweise derart angepasst, dass sich diese Abweichungen reduzieren und dass sich die Abarbeitungszeiten der entsprechenden Prozesse ihren jeweiligen Soll-Werten annähern. Insbesondere wird die Ressourcenverteilung dabei derart angepasst, dass kritischen Prozessen, die ihre jeweilige Soll-Abarbeitungszeit überschreiten, mehr Zugriff auf die Ressource gewährt wird, so dass diese Prozesse bei der Ausführung nicht negativ beeinträchtigt werden. Nicht kritischen Prozessen, deren Ist- und Soll-Abarbeitungszeiten übereinstimmen oder zumindest im Wesentlichen übereinstimmen, kann im Zuge dessen weniger Zugriff auf die Ressource gewährt werden. Beispielsweise kann dazu jedem Prozess auch ein Laufzeitprioritätswert zugewiesen sein, der die Wichtigkeit der Laufzeiterfüllung des Prozesses kennzeichnet.
-
Das vorliegende Verfahren ermöglicht es somit, während des laufenden Betriebs der Recheneinheit dynamisch und individuell zu regulieren, welche Prozesse in welchem Maße auf die gemeinsam genutzte Ressource zugreifen dürfen, so dass es nicht zu Zugriffskonflikten, Verzögerungen und gar zu Fehlern oder Instabilitäten bei der Ausführung der Prozesse kommt. Die Verteilung der Ressourcen auf die verschiedenen Prozesse wird somit von der Recheneinheit selbstständig und automatisch reguliert, individuell angepasst an die aktuell ausgeführten Anwendungen und Prozesse.
-
Zweckmäßigerweise wird die Überwachung der Abarbeitungszeiten und die Anpassung der Ressourcenverteilung in Software durch eine entsprechende Softwareeinheit durchgeführt bzw. durch ein entsprechendes Softwaremodul oder einen Softwaremechanismus. Beispielsweise kann dieser Softwaremechanismus als ein Ausführungs- oder Ressourcenmanager vorgesehen sein. Dieser Softwaremechanismus bzw. Ausführungsmanager kann insbesondere von der Prozessoreinheit der Recheneinheit ausgeführt werden.
-
Ferner ist es auch denkbar, eine eigene Hardwareeinheit in die Recheneinheit zu implementieren, welche diesen Softwaremechanismus ausführt.
-
Das Verfahren ermöglicht es ferner, die Bestimmung der bestmöglichen Ressourcenverteilung hardware- und softwareseitig zu trennen. Insbesondere können die Soll-Abarbeitungszeit und die Abarbeitungszeitverlängerung für einen jeweiligen Prozess von einem Programmierer bzw. Softwareentwickler vorgegeben werden, beispielsweise im Zug einer Herstellung- bzw. Programmierphase des jeweiligen Prozesses. Insbesondere können Soll-Abarbeitungszeit und Abarbeitungszeitverlängerung für den jeweiligen Prozess unabhängig von der speziellen Recheneinheit bzw. Hardwarekonfiguration vorgegeben werden, auf welcher der Prozess später ausgeführt wird. Somit kann den Entwicklern der einzelnen Softwareprozesse ein hohes Maß an Freiheit und Flexibilität bei der Entwicklung eingeräumt werden. Diese Vorgaben der Softwareentwickler, wie ihr jeweiliger Prozess bestmöglich auszuführen ist, wird von der Recheneinheit während ihres Betriebs automatisch berücksichtigt. Beispielsweise können die Soll-Abarbeitungszeiten zu diesem Zweck durch relative Werte z.B. in Form von Zählerwerten usw. angegeben werden und die Abarbeitungszeitverlängerungen beispielsweise jeweils als Erhöhungen von diesen Zählerwerten.
-
Die einzelnen in der Recheneinheit ausgeführten Prozesse bzw. Anwendungen können insbesondere unterschiedliche Qualitätsanforderungen bezüglich Güte bzw. Dienstgüte (engl. „Quality of Service“, QoS) haben. „QoS“ oder „Quality of Service“ ist ein Maß dafür, wie stark die Güte eines Dienstes mit den Anforderungen übereinstimmt. Je nach Art und Priorität der jeweiligen Anwendung können die einzelnen Prozesse unterschiedlich auf Verzögerungen ihrer Abarbeitung reagieren. Insbesondere kann jeder Prozess, abhängig von seiner zeitlichen Kritikalität, ein gewisses Maß an Leistungsverschlechterung in Form einer Verlängerung der Ausführungszeit aufgrund von Konflikten auf die gemeinsam genutzte Hardwareressource tolerieren, wenn er gleichzeitig mit anderen Anwendungen ausgeführt wird. Verzögerungen können sich also mehr oder weniger kritisch auf die einzelnen Prozesse und das gesamte System auswirken. Für zeitunkritische, weniger relevante Prozesse, z.B. dem Erstellen von Log- oder Protokolldateien, ergeben sich beispielsweise keine oder kaum negative Auswirkungen bei Abarbeitungsverzögerungen. Zeitkritische bzw. in Echtzeit auszuführende Prozesse, beispielsweise im Zuge der Steuerung von elektrischen Maschinen, Brennkraftmaschinen, Invertern usw., haben hingegen insbesondere nur geringen Spielraum bezüglich ihrer Abarbeitungszeiten und können nur begrenze Verzögerungen ihrer Abarbeitung tolerieren. Die Soll-Abarbeitungszeiten und die zulässigen Abarbeitungszeitverlängerungen werden zweckmäßigerweise für jeden Prozess individuell basierend auf dessen Kritikalität und Empfindlichkeit vorgegeben, insbesondere basierend auf der maximalen Erhöhung der Ausführungszeit, welche der jeweilige Prozess tolerieren kann, um korrekt zu funktionieren. Basierend auf diesen Vorgaben wird die Ressourcenverteilung im System online überwacht und dynamisch gesteuert, so dass Auswirkungen von Zugriffskonflikten insbesondere in Form von Verlängerungen der Ausführungszeiten für jeden Prozess auf den jeweiligen vorgegebenen zulässigen Wert begrenzt werden. Durch das vorliegende Verfahren kann somit besonders zweckmäßig die Dienstgüte (Quality of Service) für die verschiedenen Prozesse und Anwendungen gewährleistet werden.
-
Auf herkömmliche Weise werden gemeinsam genutzte Ressourcen oftmals statisch bereitgestellt bzw. verteilt und zumeist unter Berücksichtigung sog. Worst-Case-Konkurrenzszenarien konfiguriert. Eine solche statische Ressourcenverteilung kann zu einer ineffizienten Nutzung der Systemressourcen führen. Beispielsweise sind aus „Marco Caccamo, Rodolfo Pellizzoni, Lui Sha, Gang Yao, and Heechul Yun. 2013. MemGuard: Memory bandwidth reservation system for efficient performance isolation in multi-core platforms. In Proceedings of the 2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium (RTAS) (RTAS '13). IEEE Computer Society, Washington, DC, USA, 55-64.“ ein Mechanismus bzw. ein Verfahren bekannt, bei dem eine minimale Speicherbandbreite für verschiedene CPU-Kerne innerhalb eines CPU-Clusters garantiert wird. Dies funktioniert, indem einem Kern ein Budget, also ein bestimmter Wert bzw. Anteil für die Nutzung der gesamten zur Verfügung stehenden Speicherbandbreite zugewiesen wird und indem Cache-Fehler der letzten Ebene in einem Regelungsintervall überwacht werden und der Kern dann angehalten wird, wenn das Budget innerhalb eines Regelungsintervalls überschritten wird. Außerdem bietet dieses Verfahren eine Möglichkeit, die Speicherbandbreite basierend auf dem vorherigen Nutzungsverlauf dynamisch zuzuweisen. Die Vorhersage betrachtet jedoch immer die vorherigen Intervalle und ist nicht ereignisgesteuert. Es wird eine statische Zuweisung von Budgets zu jedem Kern angenommen und dann das nicht verwendete Budget neu verteilt.
-
Eine andere herkömmliche Möglichkeit speicherbewusster Planung ist es beispielsweise, die Aufgaben, die zu einem bestimmten Zeitpunkt auf verschiedenen Kernen gemeinsam durchgeführt werden sollen, vorab z.B. durch einen Planer festzulegen, sodass die Speichergrenzen nicht erweitert werden können. Auch kann die Anwendung in Speicher- und Rechenphasen geordnet werden, und die verschiedenen Speicherphasen von Anwendungen auf verschiedenen Kernen können geplant werden. Es ist jedoch ein Ansatz wünschenswert, der unabhängig von der Planungslogik ist und das Anwendungsverhalten nicht verändert.
-
Herkömmlicherweise bieten eingebettete Hochleistungsplattformen hardwareseitig z.B. zunehmend QoS-Module für die Verbindung zwischen Mastern (z.B. CPU, GPU, DMA) und dem Hauptspeicher. Diese QoS-Module helfen bei der Regulierung des Datenverkehrs basierend auf verschiedenen Parametern wie ausstehenden Transaktionen, Ratenregulierung oder latenzbasierter Regulierung. Beispielsweise können die Register auf der Verbindung so konfiguriert werden, dass ein Limit für die ausstehenden Transaktionen festgelegt wird, beispielsweise für die GPU, damit die Verbindung nicht mit Speichertransaktionen überflutet wird. Die Verbindung drosselt dann den eingehenden Datenverkehr von der GPU, sobald das Limit überschritten wird, sodass andere Master auf den Speicher zugreifen können. Typischerweise sind solche Module über Register programmierbar und steuern die an die Verbindung angeschlossenen Hauptkomponenten.
-
Herkömmlicherweise behandelt ein solches QoS-Modul den gesamten Cluster an Kernen jedoch zumeist als einen einzigen Master, da der gesamte Cluster an einem einzigen Port bzw. einer einzigen Schnittstelle mit der Verbindung verbunden ist. Damit bietet das QoS-Modul ggf. nur eine Regulierung auf der Ebene des Clusters und kann möglicherweise nicht zwischen verschiedenen Kernen differenzieren, was das Problem einer kernübergreifenden Konkurrenz nicht löst. Ferner ist eine statische Konfiguration der Regelungsparameter möglicherweise nicht ausreichend, um den gemeinsamen Speicher effizient zu nutzen.
-
Ferner wird die QoS-Regulierung verschiedener Kerne innerhalb eines CPU-Clusters herkömmlicherweise nicht von der darunterliegenden Hardware unterstützt. Das bedeutet, dass die Hardware-QoS-Unterstützung auf Interconnect-Ebene die Kerne nur gegen andere Störquellen schützen kann, nicht aber gegen die anderen Kerne innerhalb desselben Clusters. Daher stellen herkömmlicherweise oftmals Software-Mechanismen on top notwendige Interferenzregulierung in Kombination mit der QoS-Unterstützung auf Interconnect-Ebene bereit.
-
Jedoch wird in derartigen softwarebasierten Regulierungsmechanismen oftmals nur ein statisches Ressourcenbudget für jeden Kern zugewiesen. Ein Ressourcenbudget wird dabei oftmals auf die höchste Anzahl von Ressourcenzugriffen innerhalb eines bestimmten Regelintervalls eingestellt, was zu einer enormen Verlangsamung von Nicht-Echtzeit-Kernen führen könnte. Ferner kann es sich als schwierig erweisen, solche Mechanismen zu konfigurieren. Es erfordert Expertenwissen über die zugrundeliegende Hardware und spezifische Workloads. Beispielsweise bei großen Software-Stacks, bestehend aus Hypervisor, Betriebssystem, Middleware und zusätzlicher Virtualisierung, wie z.B. Docker-Containern, kann sich dies als sehr aufwendig erweisen. Falsch konfigurierte Systeme können zu enormen Leistungseinbußen führen oder reduzieren Störeffekte nicht.
-
Im Gegensatz zu solchen Methoden wird durch das vorliegende Verfahren ein Softwaremechanismus vorgeschlagen, der sich ändernde Ressourcennutzungsmuster von Prozessen, z.B. sich ändernde Speichernutzungsmuster, automatisch berücksichtigt und diese Regelungsparameter in den QoS-Modulen neu konfigurieren kann. Das Verfahren stellt eine Möglichkeit vor, Ressourcen wie Speicherbandbreite für verschiedene Master - dabei kann es sich sowohl um einzelne Prozessoreinheiten als auch um Gruppen hiervon (bzw. von Kernen) handeln - weiterhin auf der Verbindungsebene dynamisch zu regulieren und zusätzlich innerhalb einer Gruppe von Prozessoreinheiten, also innerhalb eines Masters, die Ressourcen zwischen den Kernen zu regulieren.
-
Vorteilhafterweise werden das Bestimmen der aktuellen Ist-Abarbeitungszeiten, das Vergleichen der bestimmten Ist-Abarbeitungszeiten mit den jeweiligen zugewiesenen Soll-Abarbeitungszeiten bzw. mit der Summe der jeweiligen zugewiesenen Soll-Abarbeitungszeiten und der jeweiligen zugewiesenen Abarbeitungszeitverlängerung und das Anpassen der Ressourcenverteilung zyklisch in vorgegebenen Überwachungsintervallen durchgeführt. Somit kann bei einem aktuellen Überwachungsereignis die Abweichung der aktuellen Ist-Abarbeitungszeiten von den jeweiligen Soll-Werten bestimmt werden und basierend auf der Abweichung kann die Ressourcenverteilung angepasst werden. In einem nachfolgenden Überwachungsereignis kann die Auswirkung dieser Anpassung auf die Abarbeitungszeiten beobachtet werden.
-
Bevorzugt wird die Ressourcenverteilung in Abhängigkeit davon angepasst, ob die Ist-Abarbeitungszeit wenigstens eines Prozesses um mehr als die jeweilige zugewiesene Abarbeitungszeitverlängerung von der jeweiligen zugewiesenen Soll-Abarbeitungszeit abweicht. Zweckmäßigerweise wird die Ressourcenverteilung derart dynamisch angepasst, so dass möglichst keine der zulässigen Abarbeitungszeitverlängerungen überschritten wird und so, dass es nicht zu Instabilitäten des Systems kommt.
-
Alternativ oder zusätzlich wird die Ressourcenverteilung vorzugsweise in Abhängigkeit davon angepasst, wie stark die Ist-Abarbeitungszeiten der einzelnen Prozesse von den jeweiligen Soll-Abarbeitungszeiten abweichen. Insbesondere wird die Ressourcenverteilung in diesem Fall dynamisch geregelt, so dass eine optimale Verteilung der Ressource gefunden werden kann und für die einzelnen Prozesse jeweils eine bestmögliche Abarbeitungszeit möglichst nahe an dem vorgegeben Soll-Wert erreicht wird.
-
Vorteilhafterweise werden die aktuellen Ist-Abarbeitungszeiten der einzelnen Prozesse mit Hilfe wenigstens eines Leistungszählers bestimmt. Leistungszähler bzw. Hardware-Leistungszähler oder Hardware-Zähler (engl. „performance monitoring counter“, PMC, oder „performance monitoring unit“, PMU) sind Komponenten von Prozessoreinheiten bzw. Mikroprozessoren, beispielsweise in Form von speziellen Registern, welche bestimmte Vorgänge oder Aktivitäten in der Recheneinheit messen bzw. zählen. Zweckmäßigerweise werden somit Daten von entsprechenden Leistungszählern gesammelt, um Anstiege der Ausführungszeiten der Prozesse zu überwachen, den die Prozesse während ihrer Ausführung erleiden. Insbesondere können dabei Daten von einer Kombination aus mehreren Leistungszählern berücksichtigt werden. Insbesondere wird die Überwachung durch die Leistungszähler zyklisch in den vorgegebenen Überwachungsintervallen durchgeführt. Zweckmäßigerweise kann der Softwaremechanismus bzw. Ausführungsmanager Informationen von diesen Leistungszählern einlesen und mit den hinterlegten vorgegebenen Soll-Abarbeitungszeiten und Abarbeitungszeitverlängerungen vergleichen.
-
Gemäß einer bevorzugten Ausführungsform werden im Zuge der Ressourcenverteilung Zugriffe der Vielzahl von Prozessen auf die gemeinsam genutzte Ressource anhand von verschiedenen Verteilungsparametern reguliert bzw. organsiert oder geordnet. Insbesondere können unterschiedliche Verteilungsmechanismen bzw. Kontroll- oder Organisationsmechanismen vorgesehen sein, welche gemäß diesen Verteilungsparametern jeweils auf unterschiedliche Weise Teile der Ressource einzelnen Prozessorkernen bzw. Prozessen zuweisen. Besonders zweckmäßig ist zu diesem Zweck eine Vielzahl von QoS-Modulen bzw. QoS-Mechanismen vorgesehen, welche einen jeweiligen Verteilungsmechanismus anhand eines jeweiligen Verteilungsparameters regulieren.
-
Vorzugsweise werden in Abhängigkeit von dem Ergebnis des Vergleichs der Ist-Abarbeitungszeiten mit den Soll-Abarbeitungszeiten bzw. mit der Summe der jeweiligen Soll-Abarbeitungszeiten und den Abarbeitungszeitverlängerungen einer oder mehrere der Verteilungsparameter angepasst. Die verschiedenen Verteilungsparameter bieten flexible Möglichkeiten, um die Verteilung der Ressource anzupassen. Insbesondere können in Abhängigkeit von den Vorgaben an die einzelnen Prozesse, also in Abhängigkeit von den Soll-Abarbeitungszeiten und den Abarbeitungszeitverlängerungen, Soll-Werte für die Verteilungsparameter bestimmt werden. Zweckmäßigerweise werden somit die den Soll-Abarbeitungszeiten und Abarbeitungszeitverlängerungen in QoS-spezifische Sollwerte bzw. Tuning-Parameter für verschiedene Hardware- und Software-QoS-Mechanismen übersetzt. Insbesondere kann der Softwaremechanismus bzw. Ausführungsmanager zum Bestimmen und Vergleichen der Ist-Abarbeitungszeiten basierend auf dem aktuellen Vergleichsergebnis die einzelnen QoS-Module bzw. QoS-Mechanismen anweisen, die jeweiligen Verteilungsparameter anzupassen. Der Softwaremechanismus kommuniziert zweckmäßigerweise die QoS-spezifischen Sollwerte an die einzelnen QoS-Modul bzw. QoS-Mechanismen, welche die jeweiligen Verteilungsparameter entsprechend abstimmt.
-
Gemäß einer vorteilhaften Ausführungsform werden Beziehungen bzw. Zusammenhänge oder Korrelationen zwischen der Anpassung einzelner Verteilungsparameter und der sich daraus ergebenden Veränderung der Ist-Abarbeitungszeiten einzelner Prozesse bestimmt bzw. erlernt. Diese bestimmten bzw. erlernten Beziehungen werden verwendet, um in Abhängigkeit von dem Ergebnis des Vergleichs der Ist-Abarbeitungszeiten mit den Soll-Abarbeitungszeiten bzw. der Summe aus Soll-Abarbeitungszeiten und den Abarbeitungszeitverlängerungen einen oder mehrere der Verteilungsparameter anzupassen. Insbesondere kann der Softwaremechanismus im Zuge maschinellen Lernens bzw. mittels eines Algorithmus zum maschinellen Lernen entsprechende Korrelationen zwischen Verteilungsparameter und Abarbeitungszeiten erlernen. Insbesondere können diese Beziehungen zu einem ersten Zeitpunkt bestimmt werden, z.B. im Zuge einer Lernphase, und zu einem späteren zweiten Zeitpunkt verwendet werden, insbesondere im Zuge eines regulären Betriebs der Recheneinheit.
-
Vorteilhafterweise wird die Ressourcenverteilung angepasst, indem ein Teil der Ressource, welcher einem ersten Prozess zugewiesen ist, teilweise oder komplett einem zweiten Prozess zugewiesen wird. Somit kann die Ressource teilweise umverteilt werden, beispielsweise von einem ersten Prozess, dessen Ist- und Soll-Abarbeitungszeiten nahe beieinander liegen oder welcher z.B. kein zeitkritischer Prozess ist, zu einem zweiten Prozess, dessen Abarbeitung nicht verzögert werden soll.
-
Alternativ oder zusätzlich kann die Ressourcenverteilung angepasst werden, indem vorzugsweise eine Anzahl von auszuführenden Transaktionen bzw. Operationen für ein vorgegebenes Zeitintervall, insbesondere für ein nächstes Überwachungsintervall, reduziert wird. Beispielsweise können nicht-zeitkritische Transaktionen aufgeschoben werden, um zeitkritischen Prozessen Zugriff auf die Ressource zu gewähren.
-
Ferner kann die Ressourcenverteilung alternativ oder zusätzlich angepasst werden, indem vorzugsweise eine Ausführungspriorität eines bestimmten Prozesses erhöht wird, insbesondere eines Prozesses, dessen Ist-Abarbeitungszeit um mehr als die jeweilige zugewiesene Abarbeitungszeitverlängerung von der jeweiligen zugewiesenen Soll-Abarbeitungszeit abweicht. Diesem höher priorisiertem Prozess wird zweckmäßiger weise schneller Zugriff auf die Ressource gewährt als Prozessen mit geringerer Ausführungspriorität.
-
Alternativ oder zusätzlich kann die Ressourcenverteilung bevorzugt angepasst werden, indem die Ressource oder zumindest ein Teil der Ressource exklusiv einem bestimmten Prozess zugewiesen wird. Beispielsweise kann somit einem zeitkritischen Prozess, der aufgrund von Zugriffskonflikten verzögert wird, exklusiver Zugriff auf die Ressource oder einem Teil davon gewährt werden.
-
Vorteilhafterweise wird die Ressourcenverteilung alternativ oder zusätzlich angepasst, indem die Ressource partitioniert wird und eine dieser Partitionen exklusiv einem bestimmten Prozess zugewiesen wird. Beispielsweise kann im Zuge dessen ein gemeinsam genutzter Speicher in eine Vielzahl einzelner Speicherbereiche unterteilt werden, welche flexibel einzelnen Prozessen zugewiesen werden können.
-
Wenn die Ist-Abarbeitungszeiten mehrerer Prozesse jeweils um mehr als die jeweilige zugewiesene Abarbeitungszeitverlängerung von der jeweiligen zugewiesenen Soll-Abarbeitungszeit abweichen, besteht die Gefahr, dass es aufgrund von Zugriffkonflikten bei all diesen Prozessen zu Problemen oder Instabilitäten kommen kann. Insbesondere ist es in diesem Fall von Bedeutung, zu priorisieren, in welcher Reihenfolge diese Prozesse bei der Anpassung der Ressourcenverteilung berücksichtigt werden. Bevorzugt werden in diesem Fall die jeweiligen zugewiesenen Abarbeitungszeitverlängerungen dieser Prozesse basierend auf einer Laufzeitpriorität dieser Prozesse angepasst. Besonders zweckmäßig wird dabei für niedrig priorisierte Prozesse die jeweilige zugewiesene Abarbeitungszeitverlängerung um einen vorgegebenen Wert erhöht. Somit kann insbesondere erreicht werden, dass höher priorisierte zeitkritische Prozesse bei der Ressourcenverteilung priorisiert behandelt werden. Alternativ oder zusätzlich wird vorzugsweise abhängig von einer Laufzeitpriorität dieser Prozesse iterativ bzw. konsekutiv oder nacheinander für jeden dieser Prozesse jeweils die Ressourcenverteilung angepasst, insbesondere beginnend bei einem höchst priorisiertem Prozess. Somit wird zweckmäßigerweise zunächst für einen höchst priorisierten Prozess die Ressourcenverteilung angepasst und anschließend werden iterativ die übrigen Prozesse entsprechend abgearbeitet.
-
Die vorliegende Erfindung eignet sich in für eine Vielzahl von verschiedenen Anwendungsbereichen. Besonders vorteilhaft eignet sich die Erfindung für den (Kraft-) Fahrzeugbereich, wobei die Recheneinheit vorteilhafterweise als ein Steuergerät eines (Kraft-) Fahrzeugs ausgebildet ist und wobei die einzelnen Prozesse zum Steuern von Fahrzeugfunktionen ausgeführt werden. Von der Recheneinheit ausgeführte Prozesse können beispielsweise sicherheitskritische Funktionen umfassen, welche zum sicheren Betrieb und zur Steuerung des Fahrzeugs ausgeführt werden, beispielsweise im Zuge einer Motorsteuerung oder im Zuge von Fahrassistenzfunktionen usw. Durch das Verfahren kann besonders zweckmäßig ermöglicht werden, dass derartige sicherheitskritische und insbesondere zeitkritische, in Echtzeit auszuführende Prozesse ihre jeweiligen Echtzeitbedingungen erfüllen und nicht aufgrund von Zugriffskonflikten auf gemeinsam genutzte Ressourcen des Steuergeräts, insbesondere auf gemeines genutzte Speicher, verzögert werden. Sicherheit bzw. Ausfallsicherheit und Integrität des Steuergeräts können durch das vorliegende Verfahren erhöht werden. Insbesondere können durch das Verfahren Sicherheitsanforderungen im (Kraft-) Fahrzeugbereich erfüllt werden, wie sie beispielsweise in der Norm ISO 26262 oder insbesondere von dem sog. „Automotive Safety Integrity Level“ (ASIL), eine von der ISO 26262 spezifizierte Sicherheitsanforderungsstufe für sicherheitsrelevante Systeme in Kraftfahrzeugen, vorgegeben werden.
-
Eine erfindungsgemäße Recheneinheit, z.B. ein Steuergerät eines Kraftfahrzeugs, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
-
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
-
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
-
Figurenliste
-
- 1 zeigt schematisch eine bevorzugte Ausgestaltung einer erfindungsgemäßen Recheneinheit, die dazu eingerichtet ist, eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens durchzuführen.
- 2 zeigt schematisch eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens als ein Blockdiagramm.
-
Ausführungsform(en) der Erfindung
-
In 1 ist eine Recheneinheit, hier beispielsweise eines Fahrzeugs, beispielsweise ein Steuergerät, schematisch dargestellt und mit 100 bezeichnet.
-
Das Steuergerät 100 weist eine Prozessoreinheit mit zwei Prozessorkernen 110 und 120 auf. Von diesen Prozessorkernen 110, 120 wird jeweils eine Vielzahl von Prozessen 111, 112, 113, 114 und 121, 122, 123, 124 ausgeführt. Es versteht sich, dass die Prozessoreinheit auch eine größere Anzahl an Prozessorkernen aufweisen kann und dass ferner jeweils auch eine größere Anzahl an Prozessen auf den einzelnen Prozessorkernen ausgeführt werden kann.
-
Das Steuergerät 100 kann beispielsweise ein Motorsteuergerät zum Steuern einer elektrischen Maschine des Fahrzeugs sein. Die einzelnen Prozessen 111, 112, 113, 114, 121, 122, 123, 124 können sicherheitskritische Funktionen zum sicheren Betrieb des Fahrzeugs und zum Steuern der Maschine umfassen.
-
Die Prozesse 111, 112, 113, 114, 121, 122, 123, 124 können gemäß einer vorgegebenen Ressourcenverteilung gemeinsam auf eine Ressource 130 zugreifen, beispielsweise auf eine gemeinsam genutzte Speichereinheit, z.B. auf einen als DRAM ausgebildeten Arbeitsspeicher. Zu diesem Zweck sind die Prozessorkernen 110, 120 über eine Datenverbindung, z.B. einen Datenbus, gemeinsam an den Speicher 130 angebunden.
-
Durch den gemeinsamen Zugriff auf den Speicher kann es zu Verzögerungen in der Ausführung der einzelnen Prozesse kommen. Um derartigen Verzögerungen entgegenzuwirken, kann die Ressourcenverteilung während des Betriebs des Steuergeräts dynamisch angepasst werden. Zu diesem Zweck ist das Steuergerät, insbesondere programmtechnisch, dazu eingerichtet, eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens durchzuführen, wie sie in 2 schematisch als ein Blockdiagramm dargestellt ist und nachfolgend erläutert werden soll.
-
In einem (vorbereitenden) Schritt 210 werden den Prozessen 111, 112, 113, 114, 121, 122, 123, 124 jeweils eine Soll-Abarbeitungszeit und eine Abarbeitungszeitverlängerung zugewiesen. Innerhalb dieser Soll-Abarbeitungszeiten sollen die einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 jeweils abgearbeitet werden. Eine Ist-Abarbeitungszeit der einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 soll von der jeweiligen zugewiesenen Soll-Abarbeitungszeit maximal um die jeweilige zugewiesene Abarbeitungszeitverlängerung abweichen.
-
Insbesondere können diese Soll-Abarbeitungszeiten und Abarbeitungszeitverlängerung von einem Programmierer bzw. Softwareentwickler beispielsweise im Zug einer Herstellung- bzw. Programmierphase der jeweiligen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 bestimmt werden. Die Soll-Abarbeitungszeit kann z.B. einer zu erwartenden Laufzeit entsprechen, wenn der jeweilige Prozess isoliert in einer Recheneinheit mit exklusivem Zugriff auf einen Speicher ausgeführt wird. Eine Summe der Soll-Abarbeitungszeit und der Abarbeitungszeitverlängerung kann als ein zulässiger Schwell- bzw. Grenzwert vorgegeben werden, um welchen sich die Abarbeitungszeit maximal verlängern darf, damit es aufgrund von gemeinsamen Zugriffen auf den Speicher nicht zu Instabilitäten kommt. Soll-Abarbeitungszeiten und Abarbeitungszeitverlängerungen werden insbesondere basierend auf einer Kritikalität bzw. Priorität, ferner insbesondere basierend auf Echtzeitanforderungen der jeweiligen Prozesse vorgegeben.
-
Die Soll-Abarbeitungszeiten sowie die Abarbeitungszeitverlängerungen können jeweils beispielsweise als absolute Zeitwerte oder auch als relative Werte angegeben werden. Beispielsweise können die Soll-Abarbeitungszeiten jeweils als Zählerwerte eines Leistungszählers, Hardware-Leistungszähler oder Hardware-Zählers vorgegeben werden und die Abarbeitungszeitverlängerungen jeweils als prozentuale Abweichungen von diesen Zählerwerten. Aus diesen Zählerwerten ergeben sich die entsprechenden Laufzeiten bzw. die konkreten Zeitwerte für die Soll-Abarbeitungszeiten und für die Abarbeitungszeitverlängerungen dann durch die Zielhardwareplattform.
-
Die Soll-Abarbeitungszeiten und die Abarbeitungszeitverlängerungen werden in dem Steuergerät 100 hinterlegt, insbesondere in einem Ausführungsmanager 220, welcher als Softwaremechanismus bzw. Softwareeinheit oder Softwaremodul in dem Steuergerät 100 ausgeführt wird oder beispielsweise auch als ein separates Hardwaremodul vorgesehen sein kann. Während der Ausführung der einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 in dem Steuergerät 100 bestimmt der Ausführungsmanager 220 aktuelle Ist-Abarbeitungszeiten, innerhalb welcher die einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 abgearbeitet werden.
-
Diese aktuellen Ist-Abarbeitungszeiten werden beispielsweise mit Hilfe wenigstens eines Leistungszählers bestimmt. Das Steuergerät 100 weist insbesondere eine Überwachungseinheit 230 mit einer Vielzahl von Leistungszähler, Hardware-Leistungszählern bzw. Hardware-Zählern (engl. „performance monitoring counter“, PMC, oder „performance monitoring unit“, PMU) 231, 232, 233 auf, jeweils z.B. in Form von speziellen Registern, welche bestimmte Vorgänge oder Aktivitäten in dem Steuergerät 100 messen bzw. zählen. Der Ausführungsmanager 220 liest Informationen von diesen Leistungszählern 231, 232, 233 ein und bestimmt basierend darauf die aktuellen Ist-Abarbeitungszeiten der einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124.
-
Beispielsweise können Ausführungszyklen von Prozessen mittels des Leistungszählers 231 überwacht werden. Beispielsweise können in einer ARM-Prozessorarchitektur von dem Leistungszähler 232 die Ereignisse OxE7/OxE8 gemessen werden, um Speicherstillstände aufgrund von Schreib- oder Leseoperationen zu berechnen. Ferner können mittels des Leistungszählers 233 beispielsweise Level-2-Cache-Misses und L2-Cache-Write-Backs überwacht werden, um Verzögerungen aufgrund von Speicherzugriffen zu bestimmen.
-
Der Ausführungsmanager 220 vergleicht die bestimmten Ist-Abarbeitungszeiten der einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 mit den jeweiligen zugewiesenen Soll-Abarbeitungszeiten und ferner mit der Summe der jeweiligen Soll-Abarbeitungszeiten und der jeweiligen Abarbeitungszeitverlängerungen. In Abhängigkeit von einem Ergebnis dieses Vergleichs wird die Ressourcenverteilung angepasst. Abweichungen der Ist- von den zugewiesenen Soll-Zeiten deuten insbesondere auf Konflikte bei den Speicherzugriffen und auf daraus resultierende Abarbeitungsverzögerungen hin. Abhängig von diesen Abweichungen wird die Ressourcenverteilung dynamisch angepasst.
-
Im Zuge der Ressourcenverteilung werden die Zugriffe der einzelnen Prozesse 111, 112, 113, 114, 121, 122, 123, 124 auf den gemeinsamen Speicher 130 insbesondere anhand von verschiedenen Verteilungsparametern reguliert. Zu diesem Zweck ist insbesondere eine Vielzahl von Verteilungs-, Kontroll- oder Organisationsmechanismen 240 vorgesehen sein, welche gemäß diesen Verteilungsparametern jeweils auf unterschiedliche Weise Teile der Ressource 130 einzelnen Prozessen zuweisen. Besonders zweckmäßig ist zu diesem Zweck eine Vielzahl von QoS-Modulen, QoS-Mechanismen bzw. QoS-Controllern 241, 242, 243, 244 vorgesehen, welche einen jeweiligen Verteilungsmechanismus anhand eines jeweiligen Verteilungsparameters regulieren.
-
In Abhängigkeit von dem Ergebnis des Vergleichs werden einer oder mehrere der Verteilungsparameter angepasst. Insbesondere übersetzt der Ausführungsmanager 220 zu diesem Zweck die Soll-Abarbeitungszeiten und Abarbeitungszeitverlängerungen in QoS-spezifische Sollwerte bzw. Tuning-Parameter für verschiedene Hardware- und Software-QoS-Mechanismen 240. Weichen einzelne Ist-Abarbeitungszeiten von den jeweiligen Soll-Abarbeitungszeiten ab, weist der Ausführungsmanager 220 den jeweiligen QoS-Controller 240 an, den entsprechenden Verteilungsparameter anzupassen.
-
In einem Schritt 250 wird die Ressourcenverteilung entsprechend angepasst und die Prozesse greifen gemäß dieser angepassten Ressourcenverteilung auf den gemeinsamen Speicher 130 zu. Daraufhin wird, angedeutet durch Bezugszeichen 260, von die aktuellen Ist-Abarbeitungszeiten erneut von den Leistungszählern 230 bestimmt und von dem Ausführungsmanager 220 mit den Soll-Zeiten bzw. den zulässigen Verlängerungen verglichen. Somit kann insbesondere ein Regelkreis implementiert werden und die Ressourcenverteilung kann zweckmäßigerweise dynamisch reguliert bzw. geregelt werden. Insbesondere kann der Ausführungsmanager 220 im Zuge dessen zyklisch in vorgegebenen Überwachungsintervallen die Ist-Abarbeitungszeiten bestimmen, mit den vorgegebenen Werten vergleichen und die Ressourcenverteilung anpassen. Ferner kann der der Ausführungsmanager 220 auf diese Weise Beziehungen, Zusammenhänge bzw. Korrelationen zwischen der Anpassung einzelner Verteilungsparameter und der sich daraus ergebenden Veränderung der Ist-Abarbeitungszeiten einzelner Prozesse erlernen, z.B. im Zuge maschinellen Lernens. Diese erlernten Beziehungen können in nachfolgenden Überwachungsintervallen zur Anpassung der Ressourcenverteilung verwendet werden. Somit kann die Anpassung der Ressourcenverteilung stets verbessert werden.
-
Jeder QoS-Controller ist für einen bestimmten QoS-Mechanismus zuständig und stimmt die QoS-Parameter entsprechend ab. Beispielsweise kann der QoS-Controller 241 für eine Regelung der Speicherbandbreite vorgesehen sein. Wenn z.B. von dem Ausführungsmanager 220 festgestellt wird, dass die Ist-Abarbeitungszeit des zeitkritischen Prozesses 111 um mehr als die vorgegebene Abarbeitungszeitverlängerung von der zugewiesenen Soll-Abarbeitungszeit abweicht, weist der Ausführungsmanager 220 den QoS-Controller 241 an, für die Dauer des nächsten Überwachungsintervalls die Speicherbandbreite, die den anderen Prozessen 112, 113, 114, 121, 122, 123, 124 zugewiesen ist, zu reduzieren und stattdessen dem besagten zeitkritischen Prozess 111 zuzuweisen.
-
Ferner kann beispielsweise der QoS-Controller 242 zur Steuerung eines Interconnect vorgesehen sein. Wenn der Ausführungsmanager 220 z.B. feststellt, dass ein Prozess auf einem Kern, z. B. auf dem Kern 110, die zulässige Abarbeitungszeitverlängerung überschreitet, kann der Ausführungsmanager 220 den QoS-Controller 242 beispielsweise anweisen, die Anzahl der ausstehenden Transaktionen von anderen Kernen 120 für die Dauer des nächsten Überwachungsintervalls zu reduzieren oder die Priorität von Transaktionen auf dem Kern 110 zu erhöhen, damit diese schneller abgearbeitet werden.
-
Beispielsweise kann der QoS-Controller 243 für eine Cache-Hierarchie zuständig sein. Wenn der Ausführungsmanager 220 z.B. feststellt, dass die Abarbeitungszeit des zeitkritischen Prozesses 111 die zulässige Abarbeitungszeitverlängerung überschreitet, kann der Ausführungsmanager 220 den QoS-Controller 243 anweisen, den Cache zu partitionieren, z.B. mittels Software-Mechanismen wie Cache-Coloring oder Hardware-Mechanismen, wie sie von ARM DynamiQ-CPU-Architekturen bereitgestellt werden, so dass Teile des Cache exklusiv für den Prozess 111 reserviert werden, was Störeffekte reduziert.
-
Da es möglicherweise nicht möglich ist, die Anforderungen aller Anwendungen in allen Situationen gleichzeitig zu erfüllen (z.B. aufgrund von transient ansteigenden Konkurrenzszenarien), entscheidet der Ausführungsmanager 220 bei Bedarf, welche Prozesse priorisiert werden. Dies kann z.B. durch Vorgabe einer vordefinierten Degradationsreihenfolge, z.B. basierend auf Kritikalität und Sicherheitsanforderungen, geschehen, um die Performance von höherpriorisierten Prozessen zu gewährleisten. Wenn der Ausführungsmanager 220 feststellt, dass die Ist-Abarbeitungszeiten mehrerer Prozesse jeweils um mehr als die zugewiesene Abarbeitungszeitverlängerung von der zugewiesenen Soll-Abarbeitungszeit abweichen, kann der Ausführungsmanager 220 zweckmäßigerweise die zugewiesenen Abarbeitungszeitverlängerungen von Prozessen mit niedriger Priorität erhöhen und dann den Regelkreis ausführen, um diese geänderten Werte zu erfüllen. Alterativ oder zusätzlich kann der Ausführungsmanager 220 zweckmäßigerweise abhängig von einer Laufzeitpriorität dieser Prozesse iterativ für jeden dieser Prozesse jeweils die Ressourcenverteilung im Zuge eines Regelkreises anpassen, beginnend bei einem höchst priorisiertem Prozess.
-
Im Rahmen des vorliegenden Verfahrens können somit verschiedene QoS-Parameter in der Software/Hardware dynamisch geregelt werden, die durch die von einem oder mehreren Leistungszählern (PMC) erhaltenen Informationen gesteuert werden, um die von einem Benutzer festgelegten QoS-Anforderungen der Anwendungen zu erfüllen. Beispielsweise können Informationen über L2-Cache-Misses und Write-Backs oder Informationen über Blockierzyklen aufgrund von Ressourcenzugriffen verwendet werden, um Budgets für gemeinsam genutzte Ressourcen für verschiedene Prozesse bzw. Prozessorkerne mit einem entsprechenden Software-Mechanismus oder anderen QoS-Mechanismen auf dem Interconnect dynamisch zu konfigurieren. Ferner können beispielsweise auch Messungen von Leistungszählern, z.B. DDR-Leistungszählern oder Leistungszählern auf dem Interconnect, verwendet werden, um verschiedene Software/Hardware-QoS-Mechanismen dynamisch zu konfigurieren. OS-Kernel-Ereignisse können beispielsweise zusätzlich verwendet werden, um die Konfiguration der QoS-Mechanismen zu steuern. Durch das vorliegende Verfahren kann somit insbesondere eine durchschnittliche Systemleistung erhöht werden und es können Leistungsgarantien für Anwendungen gewährleistet werden.
-
Mit Hilfe des vorliegenden Verfahrens können besonders zweckmäßig Hauptspeicher-Interferenzen (z.B. gemessen mit Cache-Misses des letzten Überwachungszyklus) und ferner Cache-Interferenzen kontrolliert werden, beispielsweise unter Verwendung zusätzlicher Informationen der Leistungszähler.
-
Der Ausführungsmanager reguliert sich gemäß dem vorliegenden Verfahren besonders zweckmäßig selbst, insbesondere basierend auf spezifizierten Informationen wie Kritikalität, Fristen und Sicherheitsmargen. Ein Benutzer spezifiziert insbesondere nur QoS-Anforderungen, ohne Details des Hardware/Software-Stacks zu kennen. Der Mechanismus ist somit für den Benutzer transparent und macht die Konfiguration und Nutzung aus Anwendersicht weniger komplex.
