Stehlen: Wer stiehlt CPU-Zeit von virtuellen Maschinen?

Hallo! Ich möchte in einfachen Worten über die Mechanismen der Entstehung von Diebstahl in virtuellen Maschinen und über einige nicht offensichtliche Artefakte sprechen, die wir während seiner Forschung herausfinden konnten, in die ich als technischer Direktor einer Cloud-Plattform eintauchen musste Mail.ru Cloud-Lösungen. Die Plattform läuft auf KVM.

Die CPU-Steal-Zeit ist die Zeit, in der die virtuelle Maschine keine Prozessorressourcen für ihre Ausführung erhält. Diese Zeit wird nur in Gastbetriebssystemen in Virtualisierungsumgebungen berücksichtigt. Die Gründe dafür, wohin diese zugewiesenen Ressourcen wie im Leben fließen, sind sehr vage. Aber wir beschlossen, es herauszufinden und führten sogar eine Reihe von Experimenten durch. Es ist nicht so, dass wir jetzt alles über Diebstahl wissen, aber wir werden Ihnen jetzt etwas Interessantes erzählen.

1. Was ist Diebstahl?

Steal ist also eine Kennzahl, die den Mangel an Prozessorzeit für Prozesse innerhalb einer virtuellen Maschine angibt. Wie beschrieben im KVM-Kernel-Patch, Steal ist die Zeitspanne, die der Hypervisor andere Prozesse auf dem Host-Betriebssystem ausführt, obwohl er den Prozess der virtuellen Maschine zur Ausführung in die Warteschlange gestellt hat. Das heißt, Steal wird als Differenz zwischen dem Zeitpunkt, zu dem der Prozess zur Ausführung bereit ist, und dem Zeitpunkt, zu dem dem Prozess CPU-Zeit zugewiesen wird, berechnet.

Der Kernel der virtuellen Maschine erhält die Steal-Metrik vom Hypervisor. Gleichzeitig gibt der Hypervisor nicht an, welche anderen Prozesse er ausführt, sondern nur: „Solange ich beschäftigt bin, kann ich Ihnen keine Zeit geben.“ Bei KVM wurde Unterstützung für die Diebstahlberechnung hinzugefügt Patches. Hier gibt es zwei wesentliche Punkte:

• Die virtuelle Maschine lernt vom Hypervisor, etwas zu stehlen. Das heißt, aus Sicht der Verluste handelt es sich bei Prozessen auf der virtuellen Maschine selbst um eine indirekte Messung, die verschiedenen Verzerrungen unterliegen kann.
• Der Hypervisor teilt der virtuellen Maschine keine Informationen darüber mit, was er sonst noch tut – Hauptsache, er widmet dieser Aufgabe keine Zeit. Aus diesem Grund kann die virtuelle Maschine selbst keine Verzerrungen im Diebstahlindikator erkennen, die anhand der Art konkurrierender Prozesse beurteilt werden könnten.

2. Was beeinflusst Diebstahl?

2.1. Berechnung stehlen

Tatsächlich wird Diebstahl genauso betrachtet wie die übliche CPU-Nutzungszeit. Es gibt nicht viele Informationen darüber, wie Recycling berücksichtigt wird. Wahrscheinlich, weil die Mehrheit diese Frage für offensichtlich hält. Aber auch hier gibt es Fallstricke. Eine Übersicht über diesen Prozess finden Sie unter Artikel von Brendan Gregg: Sie erfahren mehr über eine Reihe von Nuancen bei der Berechnung der Auslastung und über Situationen, in denen diese Berechnung aus folgenden Gründen fehlerhaft ist:

• Überhitzung des Prozessors, bei der Zyklen übersprungen werden.
• Aktivieren/deaktivieren Sie den Turbo-Boost, der die Taktfrequenz des Prozessors ändert.
• Eine Änderung der Länge eines Zeitintervalls, die bei der Verwendung prozessorsparender Technologien wie SpeedStep auftritt.
• Berechnung des durchschnittlichen Problems: Eine einminütige Auslastungsschätzung von 80 % kann einen kurzfristigen Anstieg von 100 % verbergen.
• Eine Spin-Sperre bewirkt, dass der Prozessor zurückgefordert wird, der Benutzerprozess jedoch keinen Fortschritt bei seiner Ausführung sieht. Infolgedessen beträgt die geschätzte Auslastung des Prozessors durch den Prozess XNUMX %, obwohl der Prozess physisch keine Prozessorzeit verbraucht.

Ich habe keinen Artikel gefunden, der eine ähnliche Berechnung für Steal beschreibt (wenn Sie es wissen, teilen Sie es in den Kommentaren). Den Quellen zufolge ist der Berechnungsmechanismus jedoch derselbe wie beim Recycling. Es ist lediglich so, dass im Kernel direkt für den KVM-Prozess (Virtual-Machine-Prozess) ein weiterer Zähler hinzugefügt wird, der die Dauer des KVM-Prozesses im Prozessorzeit-Wartezustand zählt. Der Zähler entnimmt Informationen über den Prozessor seiner Spezifikation und prüft, ob alle seine Ticks vom Prozess der virtuellen Maschine genutzt werden. Wenn alles, dann gehen wir davon aus, dass der Prozessor nur am Prozess der virtuellen Maschine beteiligt war. Andernfalls teilen wir mit, dass der Prozessor etwas anderes getan hat, es ist Diebstahl aufgetreten.

Der Steal Count-Prozess unterliegt den gleichen Problemen wie der normale Steal Count. Das heißt nicht, dass solche Probleme häufig auftreten, aber sie sehen entmutigend aus.

2.2. Arten der Virtualisierung auf KVM

Im Allgemeinen gibt es drei Arten der Virtualisierung, die alle von KVM unterstützt werden. Der Mechanismus des Diebstahls kann von der Art der Virtualisierung abhängen.

Broadcast. In diesem Fall läuft der Betrieb des Betriebssystems der virtuellen Maschine mit den physischen Geräten des Hypervisors etwa so ab:

1. Das Gastbetriebssystem sendet einen Befehl an sein Gastgerät.
2. Der Gastgerätetreiber empfängt den Befehl, generiert eine Anfrage für das BIOS des Geräts und sendet sie an den Hypervisor.
3. Der Hypervisor-Prozess übersetzt einen Befehl in einen Befehl für ein physisches Gerät und macht es so unter anderem sicherer.
4. Der Treiber des physischen Geräts akzeptiert den geänderten Befehl und sendet ihn an das physische Gerät selbst.
5. Die Ergebnisse der Befehlsausführung laufen auf demselben Weg zurück.

Der Vorteil der Übersetzung besteht darin, dass Sie damit jedes Gerät emulieren können und keine besondere Vorbereitung des Betriebssystemkerns erforderlich ist. Dafür muss man aber zunächst einmal mit der Geschwindigkeit bezahlen.

Hardware-Virtualisierung. In diesem Fall versteht das Gerät auf Hardwareebene Befehle vom Betriebssystem. Dies ist der schnellste und beste Weg. Leider wird es jedoch nicht von allen physischen Geräten, Hypervisoren und Gastbetriebssystemen unterstützt. Derzeit sind Prozessoren die wichtigsten Geräte, die Hardwarevirtualisierung unterstützen.

Paravirtualisierung. Die gebräuchlichste Option für die Gerätevirtualisierung auf KVM und im Allgemeinen der gebräuchlichste Virtualisierungsmodus für Gastbetriebssysteme. Seine Besonderheit besteht darin, dass die Arbeit mit einigen Hypervisor-Subsystemen (z. B. mit dem Netzwerk oder dem Plattenstapel) oder die Zuweisung von Speicherseiten über die Hypervisor-API erfolgt, ohne dass Befehle auf niedriger Ebene übersetzt werden müssen. Der Nachteil dieser Virtualisierungsmethode besteht darin, dass der Kernel des Gastbetriebssystems geändert werden muss, damit er über diese API mit dem Hypervisor kommunizieren kann. Dies wird jedoch normalerweise durch die Installation spezieller Treiber auf dem Gastbetriebssystem gelöst. In KVM wird diese API aufgerufen Virtio-API.

Bei der Paravirtualisierung wird im Vergleich zur Übersetzung der Weg zum physischen Gerät erheblich verkürzt, indem Befehle direkt von der virtuellen Maschine an den Hypervisor-Prozess auf dem Host gesendet werden. Dadurch können Sie die Ausführung aller Anweisungen innerhalb der virtuellen Maschine beschleunigen. Bei KVM ist dafür die virtio API zuständig, die nur für bestimmte Geräte, etwa einen Netzwerk- oder Festplattenadapter, funktioniert. Aus diesem Grund werden Virtio-Treiber in virtuellen Maschinen installiert.

Die Kehrseite dieser Beschleunigung besteht darin, dass nicht alle Prozesse, die in der virtuellen Maschine ausgeführt werden, in dieser verbleiben. Dadurch entstehen einige Spezialeffekte, die dazu führen können, dass Diebstahl auftritt. Ich empfehle, eine detaillierte Untersuchung dieses Problems mit zu beginnen Eine API für virtuelles I/O: virtio.

2.3. „Faire“ Terminplanung

Eine virtuelle Maschine auf einem Hypervisor ist in der Tat ein regulärer Prozess, der den Gesetzen der Planung (Verteilung von Ressourcen zwischen Prozessen) im Linux-Kernel folgt. Schauen wir uns ihn also genauer an.

Linux verwendet den sogenannten CFS, Completely Fair Scheduler, der seit Kernel 2.6.23 zum Standard-Scheduler geworden ist. Um diesen Algorithmus zu verstehen, können Sie die Linux-Kernel-Architektur oder die Quelle lesen. Der Kern von CFS liegt in der Verteilung der Prozessorzeit zwischen Prozessen in Abhängigkeit von der Dauer ihrer Ausführung. Je mehr CPU-Zeit ein Prozess benötigt, desto weniger CPU-Zeit erhält er. Dies garantiert die „faire“ Ausführung aller Prozesse – so dass ein Prozess nicht ständig alle Prozessoren belegt und auch andere Prozesse ausgeführt werden können.

Manchmal führt dieses Paradigma zu interessanten Artefakten. Langjährige Linux-Benutzer werden sich sicherlich an das Einfrieren eines normalen Texteditors auf dem Desktop erinnern, während ressourcenintensive Anwendungen wie der Compiler gestartet wurden. Dies geschah, weil nicht ressourcenintensive Aufgaben von Desktop-Anwendungen mit Aufgaben konkurrierten, die aktiv Ressourcen verbrauchen, wie beispielsweise der Compiler. CFS hält dies für unfair und stoppt daher regelmäßig den Texteditor und überlässt es dem Prozessor, Compiler-Aufgaben zu übernehmen. Dies wurde mit der Mechanik behoben sched_autogroup, aber viele andere Merkmale der Verteilung der Prozessorzeit zwischen Aufgaben blieben bestehen. Tatsächlich geht es in dieser Geschichte nicht darum, wie schlecht alles in CFS ist, sondern um den Versuch, die Aufmerksamkeit darauf zu lenken, dass die „faire“ Verteilung der Prozessorzeit nicht die trivialste Aufgabe ist.

Ein weiterer wichtiger Punkt im Scheduler ist die Vorbelegung. Dies ist notwendig, um den Kicherprozess vom Prozessor zu vertreiben und andere arbeiten zu lassen. Der Prozess des Exils wird Kontextwechsel genannt, ein Prozessorkontextwechsel. Gleichzeitig wird der gesamte Kontext der Aufgabe gespeichert: der Status des Stapels, der Register usw., woraufhin der Prozess zum Warten geschickt wird und ein anderer an seine Stelle tritt. Dies ist ein teurer Vorgang für das Betriebssystem und wird selten verwendet, aber eigentlich ist daran nichts auszusetzen. Häufiges Wechseln des Kontexts kann auf ein Problem im Betriebssystem hinweisen, aber normalerweise geht es kontinuierlich weiter und weist nicht auf etwas Besonderes hin.

Eine so lange Geschichte ist nötig, um eine Tatsache zu erklären: Je mehr Prozessorressourcen ein Prozess in einem ehrlichen Linux-Scheduler zu verbrauchen versucht, desto schneller wird er gestoppt, sodass auch andere Prozesse funktionieren können. Ob das stimmt oder nicht, ist eine schwierige Frage, die bei unterschiedlicher Belastung unterschiedlich gelöst wird. Bis vor kurzem konzentrierte sich der Scheduler in Windows auf die vorrangige Verarbeitung von Desktop-Anwendungen, was dazu führen konnte, dass Hintergrundprozesse hängen blieben. Sun Solaris verfügte über fünf verschiedene Klassen von Schedulern. Als die Virtualisierung eingeführt wurde, kam eine sechste hinzu: Fair-Share-Planerweil die vorherigen fünf nicht ausreichend mit der Solaris Zones-Virtualisierung funktionierten. Ich empfehle, eine detaillierte Untersuchung dieses Problems mit Büchern wie zu beginnen Solaris-Interna: Solaris 10 und OpenSolaris-Kernel-Architektur oder Den Linux-Kernel verstehen.

2.4. Wie überwacht man Diebstahl?

Die Überwachung von Diebstahl innerhalb einer virtuellen Maschine ist wie bei jeder anderen Prozessormetrik einfach: Sie können jedes beliebige Prozessormetrik-Tool verwenden. Die Hauptsache ist, dass die virtuelle Maschine unter Linux laufen sollte. Aus irgendeinem Grund stellt Windows seinen Benutzern solche Informationen nicht zur Verfügung. 🙁

Die Ausgabe des oberen Befehls: Detailliert die Auslastung des Prozessors, in der Spalte ganz rechts - Stehlen

Die Schwierigkeit entsteht, wenn versucht wird, diese Informationen vom Hypervisor abzurufen. Sie können versuchen, den Diebstahl auf dem Host-Rechner vorherzusagen, beispielsweise anhand des Load Average (LA)-Parameters – dem Durchschnittswert der Anzahl der Prozesse, die in der Ausführungswarteschlange warten. Die Methode zur Berechnung dieses Parameters ist nicht einfach, aber wenn LA, normalisiert durch die Anzahl der Prozessor-Threads, größer als 1 ist, deutet dies im Allgemeinen darauf hin, dass der Linux-Server mit etwas überlastet ist.

Worauf warten all diese Prozesse? Die offensichtliche Antwort sind Prozessoren. Aber die Antwort ist nicht ganz richtig, denn manchmal ist der Prozessor frei und LA geht aus dem Rahmen. Erinnern wie NFS abfällt und wie LA gleichzeitig wächst. Ungefähr das Gleiche kann mit der Festplatte und mit anderen Ein-/Ausgabegeräten der Fall sein. Tatsächlich können Prozesse jedoch auf das Ende einer Sperre warten, sowohl physischer, mit dem E/A-Gerät verbundener als auch logischer Sperre, beispielsweise eines Mutex. Dazu gehören auch Sperren auf Hardwareebene (die gleiche Antwort von der Festplatte) oder auf Logik (die sogenannten Sperrprimitive, die eine Reihe von Entitäten, adaptive Mutex- und Spin-Funktionen, Semaphoren, Bedingungsvariablen, RW-Sperren und IPC-Sperren umfassen. ..).

Ein weiteres Merkmal von LA ist, dass es als Durchschnittswert für das Betriebssystem betrachtet wird. Beispielsweise konkurrieren 100 Prozesse um eine Datei und dann ist LA=50. Ein so großer Wert scheint darauf hinzudeuten, dass das Betriebssystem fehlerhaft ist. Aber für anderen schief geschriebenen Code kann dies ein normaler Zustand sein, obwohl nur er schlecht ist und andere Prozesse im Betriebssystem nicht darunter leiden.

Aufgrund dieser Mittelung (und nicht weniger als einer Minute) ist die Bestimmung von LA nicht die lohnenswerteste Aufgabe, da die Ergebnisse in bestimmten Fällen sehr unsicher sind. Wenn Sie versuchen, es herauszufinden, werden Sie feststellen, dass die Artikel auf Wikipedia und anderen verfügbaren Ressourcen nur die einfachsten Fälle beschreiben, ohne eine ausführliche Erklärung des Prozesses. Ich sende allen Interessierten noch einmal: hier zu Brendann Gregg  - Folgen Sie den Links. Wer ist faul auf Englisch - Übersetzung seines beliebten Artikels über LA.

3. Spezialeffekte

Kommen wir nun zu den wichtigsten Diebstahlsfällen, die uns begegnet sind. Ich erzähle Ihnen, wie sie sich aus all dem oben Gesagten ergeben und wie sie mit den Indikatoren auf dem Hypervisor korrelieren.

Recycling. Das einfachste und gebräuchlichste: Der Hypervisor wird recycelt. Tatsächlich gibt es viele laufende virtuelle Maschinen, einen hohen Prozessorverbrauch in ihnen, viel Konkurrenz, die Auslastung durch LA ist größer als 1 (normalisiert durch Prozessor-Threads). In allen Virtualoks verlangsamt sich alles. Auch der vom Hypervisor übertragene Diebstahl nimmt zu, es ist notwendig, die Last neu zu verteilen oder jemanden auszuschalten. Im Allgemeinen ist alles logisch und verständlich.

Paravirtualisierung versus Einzelinstanzen. Es gibt nur eine virtuelle Maschine auf dem Hypervisor, sie verbraucht einen kleinen Teil davon, verursacht aber eine große E/A-Last, beispielsweise auf einer Festplatte. Und von irgendwoher taucht ein kleiner Schnäppchenanteil darin auf, bis zu 10 % (wie mehrere Experimente zeigen).

Der Fall ist interessant. Steal taucht hier nur aufgrund von Sperren auf der Ebene paravirtualisierter Treiber auf. Innerhalb der virtuellen Maschine wird ein Interrupt erstellt, vom Treiber verarbeitet und an den Hypervisor weitergeleitet. Aufgrund der Interrupt-Verarbeitung auf dem Hypervisor sieht dies wie eine gesendete Anfrage an die virtuelle Maschine aus, sie ist zur Ausführung bereit und wartet auf den Prozessor, erhält aber keine Prozessorzeit. Die virtuelle Maschine glaubt, dass diese Zeit gestohlen wurde.

Dies geschieht in dem Moment, in dem der Puffer gesendet wird, er in den Kernelbereich des Hypervisors gelangt und wir beginnen, darauf zu warten. Obwohl er aus Sicht der virtuellen Maschine sofort zurückkehren sollte. Daher gilt diese Zeit gemäß dem Diebstahlberechnungsalgorithmus als gestohlen. Höchstwahrscheinlich gibt es in dieser Situation andere Mechanismen (z. B. die Verarbeitung weiterer Systemaufrufe), die sich jedoch nicht wesentlich unterscheiden sollten.

Scheduler gegen hoch ausgelastete virtuelle Maschinen. Wenn eine virtuelle Maschine stärker unter Diebstahl leidet als andere, liegt das genau am Scheduler. Je mehr der Prozess den Prozessor belastet, desto eher wird er vom Scheduler rausgeschmissen, damit auch der Rest funktionieren kann. Wenn eine virtuelle Maschine ein wenig verbraucht, wird sie kaum Diebstahl sehen: Ihr Prozess hat ehrlich gesagt gesessen und gewartet, ihr sollte mehr Zeit gegeben werden. Wenn die virtuelle Maschine alle ihre Kerne maximal belastet, wird sie häufiger aus dem Prozessor geworfen und versucht, ihr nicht viel Zeit zu geben.

Noch schlimmer ist es, wenn die Prozesse innerhalb der virtuellen Maschine versuchen, mehr Prozessor zu bekommen, weil sie mit der Datenverarbeitung nicht zurechtkommen. Dann wird das Betriebssystem auf dem Hypervisor aufgrund ehrlicher Optimierung immer weniger Prozessorzeit zur Verfügung stellen. Dieser Vorgang vollzieht sich wie eine Lawine und springt in die Lüfte, auch wenn andere virtuelle Maschinen dies möglicherweise kaum bemerken. Und je mehr Kerne, desto schlechter ist die Maschine, die unter die Verteilung fällt. Kurz gesagt, stark ausgelastete virtuelle Maschinen mit vielen Kernen leiden am meisten.

Niedriges LA, aber es gibt Diebstahl. Wenn LA etwa 0,7 beträgt (d. h. der Hypervisor scheint unterlastet zu sein), wird jedoch Diebstahl innerhalb einzelner virtueller Maschinen beobachtet:

• Die oben bereits beschriebene Möglichkeit mit Paravirtualisierung. Die virtuelle Maschine kann Metriken empfangen, die auf Diebstahl hinweisen, obwohl der Hypervisor gut funktioniert. Den Ergebnissen unserer Experimente zufolge überschreitet diese Diebstahloption 10 % nicht und sollte keinen wesentlichen Einfluss auf die Anwendungsleistung innerhalb der virtuellen Maschine haben.
• Der LA-Parameter wird als falsch angesehen. Genauer gesagt gilt es zu jedem bestimmten Zeitpunkt als richtig, aber im Durchschnitt über eine Minute erweist es sich als unterschätzt. Wenn beispielsweise eine virtuelle Maschine pro Drittel des Hypervisors genau eine halbe Minute lang alle Prozessoren verbraucht, beträgt LA pro Minute auf dem Hypervisor 0,15; Vier solcher virtuellen Maschinen, die gleichzeitig arbeiten, ergeben 0,6. Und die Tatsache, dass es bei jedem von ihnen eine halbe Minute lang einen wilden Diebstahl bei 25 % in Bezug auf LA gab, lässt sich nicht mehr herausholen.
• Wiederum wegen des Planers, der entschied, dass jemand zu viel aß, und diesen warten ließ. In der Zwischenzeit wechsle ich den Kontext, kümmere mich um Interrupts und kümmere mich um andere wichtige Systemdinge. Infolgedessen treten bei einigen virtuellen Maschinen keine Probleme auf, während es bei anderen zu erheblichen Leistungseinbußen kommt.

4. Andere Verzerrungen

Es gibt eine Million weitere Gründe dafür, die ehrliche Rendite der Prozessorzeit auf einer virtuellen Maschine zu verzerren. Beispielsweise erhöhen Hyperthreading und NUMA die Komplexität der Berechnungen. Sie verwirren die Wahl des Kernels für die Ausführung des Prozesses völlig, da der Scheduler Koeffizienten verwendet – Gewichte, die beim Wechseln des Kontexts die Berechnung noch schwieriger machen.

Es kommt zu Verzerrungen durch Technologien wie Turbo-Boost oder umgekehrt Energiesparmodus, die bei der Berechnung der Auslastung die Frequenz oder sogar das Zeitquantum auf dem Server künstlich erhöhen oder verringern können. Durch die Aktivierung des Turbo-Boosts verringert sich die Leistung eines Prozessor-Threads aufgrund der Leistungssteigerung eines anderen. In diesem Moment werden keine Informationen über die aktuelle Prozessorfrequenz an die virtuelle Maschine übertragen und sie geht davon aus, dass jemand ihre Zeit stiehlt (sie hat beispielsweise 2 GHz angefordert, aber halb so viel erhalten).

Generell kann es viele Gründe für Verzerrungen geben. Auf einem bestimmten System finden Sie möglicherweise etwas anderes. Es ist besser, mit den Büchern zu beginnen, zu denen ich oben Links gegeben habe, und Statistiken vom Hypervisor mit Dienstprogrammen wie perf, sysdig, systemtap usw. zu lesen Zehntel.

5. Schlussfolgerungen

1. Aufgrund der Paravirtualisierung kann es zu einem gewissen Diebstahl kommen, der als normal angesehen werden kann. Im Internet schreiben sie, dass dieser Wert 5-10 % betragen kann. Dies hängt von den Anwendungen innerhalb der virtuellen Maschine und davon ab, welche Last sie auf ihre physischen Geräte ausübt. Hier ist es wichtig, darauf zu achten, wie sich Anwendungen innerhalb virtueller Maschinen anfühlen.
2. Das Verhältnis zwischen der Belastung des Hypervisors und dem Diebstahl innerhalb der virtuellen Maschine ist nicht immer eindeutig miteinander verbunden. Beide Schätzungen des Diebstahls können in bestimmten Situationen bei unterschiedlichen Belastungen fehlerhaft sein.
3. Der Planer hat eine schlechte Einstellung gegenüber Prozessen, die viel verlangen. Er versucht, denen weniger zu geben, die mehr verlangen. Große virtuelle Maschinen sind böse.
4. Ein kleiner Diebstahl kann auch ohne Paravirtualisierung die Norm sein (unter Berücksichtigung der Last innerhalb der virtuellen Maschine, der Lasteigenschaften der Nachbarn, der Lastverteilung zwischen Threads und anderen Faktoren).
5. Wenn Sie den Diebstahl auf einem bestimmten System herausfinden möchten, müssen Sie verschiedene Optionen erkunden, Metriken sammeln, diese sorgfältig analysieren und darüber nachdenken, wie Sie die Last gleichmäßig verteilen können. Von allen Fällen sind Abweichungen möglich, die experimentell bestätigt oder im Kernel-Debugger nachgeschaut werden müssen.

Source: habr.com